Remove special global Cabal?

[mgsloan]

I believe that with support for the custom-setup stanza, #2866 , we're using the snapshot / extra-deps version of Cabal for building anything with a custom-setup stanza.

For everything else, we're using the globally installed version of Cabal (the one updated via stack setup --upgrade-cabal). This can be nice, as you can update your Cabal version without needing to modify your configurations. This means that you can get bugfixes / enhancements without updating your build configs.

This seems inconsistent to me, I think it might simplify things to always use the snapshot / extra-deps version of Cabal.

Edit: One tricky detail that I'm only considering now that I've typed all this up, is that in order to build Cabal and its dependencies, we'll need to use an existing version of Cabal - likely the global one. So it seems hard to get full consistency of Cabal version used. Thoughts on this? Just special case Cabal and its transitive deps?

We'd get the following benefits:

1. Better build reproducibility
2. Ability to use a custom Cabal - Support using a custom Cabal  #2910 - can even have it as a local package incase you need custom modifications
3. Obviates the need for enhancing stack setup to specify a cabal version to install (Add stack setup --install-cabal VERSION in addition to stack setup --upgrade-cabal. #2386 / Add --cabal-install #2995)
4. Would fix Cabal version mismatch errors caused by lacking a custom-setup stanza - Stack is using a different version of cabal to install extra-deps packages #2924
5. Obviates the need for a proposed require-cabal-version field in stack.yaml - Add "require-cabal-version" and use this to enable Cabal-1.24 build plans #2479
6. Removal of stack setup --upgrade-cabal would mean --upgrade-cabal wants write access to system ghc installation #2230 can be closed (case where it wants to write to a system ghc install)

This would add an implicit dependency on Cabal to every package. So, if Cabal or anything it depends on is installed locally, everything must be installed locally rather than in the snapshot.

[snoyberg]

Big 👎. Building Cabal is a long, slow process. We don't want to add that to the beginning of every new snapshot usage.

I'd be OK with this applying just to custom Setup.hs scripts perhaps. But I'm really not seeing enough benefit for simple build types.

[mgsloan]

Hmm, not sure if I buy that argument:

1. Package sharing between snapshots will often make recompilation of Cabal unnecessary.
2. It seems quite probable that non-trivial projects will have some transitive dependency which uses a custom build type.

It does indeed take quite a while to build, on my machine it's ~4 minutes.

To me it seems like the downsides are:

1. Still need to have the global Cabal around for building the snapshot / local Cabal and its deps. No straightforward way to have full consistency here.
2. It's a change in behavior.

I'd be OK with this applying just to custom Setup.hs scripts perhaps. But I'm really not seeing enough benefit for simple build types.

Yeah, I think it makes sense to use the snapshot / local Cabal for all custom Setup.hs, regardless of the presence of a custom-setup stanza. This'd address cases where your Setup.hs depends on packages that got built with the snapshot / local Cabal - #2924

[Tehnix]

It seems me and several others have been bitten by stack using a global version of cabal instead of the one tied to the resolver (haskell/haskell-ide-engine#315 and DanielG/ghc-mod#905).

It might be that this case is so infrequent that the work needed doesn't justify "fixing" it, but it does seem counter-intuitive that the resolver would use anything else than the one in its snapshot.

[mgsloan]

I've run into another case that I think is good evidence that Cabal version should be specified by snapshots - haskell/cabal#4137 (comment) - at least for custom setup. If we mix Cabal versions, using more recent ones for simple setup, how likely is stuff to break? Seems like that'd lead to confusing inconsistencies.

It sucks that it's using my global Cabal version (2.0), it is breaking reproducibility, as I pointed out in this issue.

Maybe the answer is to default to snapshot cabal version but allow overriding this when needed. This way, things build reliably by default.

[snoyberg]

@mgsloan I looked through that issue, but I don't understand the reproduction. Can you describe it here?

[mgsloan]

@snoyberg stack build --resolver lts-10.0 semigroupoids-5.1 with Cabal-2 installed globally

[snoyberg]

But in that case: Cabal-2 is also specified by the resolver itself. Won't this fail regardless? I'm looking for some reproducing test case that can demonstrate that a change in behavior within Stack will fix this.

[mgsloan]

I'm guessing that the snapshot is being built with Cabal-1.24. So, if this was resolved both here and in stackage-curator, then you'd get better compilation guarantees. So, semigroupoids wouldn't have ended up in a snapshot that also has Cabal-2.0.

It is not a straightforward decision. On one hand, this means that you cannot update your Cabal and expect to get fixes. On the other hand, custom setups can depend on a particular Cabal version and may not specify correct constraints, like in this case.

I'm actually leaning towards a bit of an ugly solution, which is to use the snapshot version of Cabal for custom builds, and use the global version of Cabal for simple builds. Perhaps the best option is just to leave the choice up to the user.

[phadej]

Note: if custom-setup isn't specified, the implicit setup-depends are used

http://cabal.readthedocs.io/en/latest/developing-packages.html#custom-setup-scripts (the section with bounds, it seems we miss a paragraph atm)

[snoyberg]

I'm guessing that the snapshot is being built with Cabal-1.24.

That's what I'm trying to point out: LTS 10.0 does not use Cabal 1.24, it uses 2.0.1.1 https://www.stackage.org/lts-10.0/package/Cabal-2.0.1.1