Diamond dependency issue in Setup.hs + better control of Cabal version

[mgsloan]

stack setup --upgrade-cabal allows you to vary the global Cabal version. This means that the Cabal package version used to build Setup.hs can vary from what the snapshot specifies. Usually this is ok, except for the case where you have a Setup.hs which depends on a package, which also depends on Cabal. This is a diamond dependency issue - somehow the Cabal versions need to be made consistent. A few options:

1. Treat Cabal as a special package that implicitly varies from the stackage installed version. Essentially, it'd always be an "extra-dep" when it's a dependency. The downside of this approach is that you could cause compilation errors in dependencies due to Cabal API breakages.

2. Always use the stackage version. For quite a while, this is actually how I thought it worked. The downside of this is we can't benefit from Cabal bugfixes. That would further incentivize us to hack around Cabal, rather than fixing it.

3. Continue with the current behavior, which is to fail to build the Setup.hs. Additionally, we should detect this circumstance and tell the user to make the Cabal version match either by varying the extra-dep or installing the right Cabal version. This workflow would require a better command to re-install global cabal than stack setup --upgrade-cabal - we'd need one that allows specification of a version to install.

I am leaning towards (3) because (1) and (2) both have gnarly downsides. (3) also isn't entirely ideal, since the selected Cabal version is global to the current compiler. Unfortunately, we cannot fully save our users from some gnarly corners of Setup.hs

[mgsloan]

Also, we may want to give --upgrade-cabal a major cabal version upper bound. For example, we didn't really test with Cabal-1.24, it could have changed things and broken stack. This is one context where a purely informational upper bound makes sense.

[phadej]

Can't there be two Cabals, one to build Setup.hs, and other to build packages?

FYI: with custom-setup deps, build failure of Setup.hs is something package author could fix http://www.well-typed.com/blog/2015/07/cabal-setup-deps/

[mgsloan]

Can't there be two Cabals, one to build Setup.hs, and other to build packages?

No, then Setup.hs can't depend on those other packages.

Yes, support of custom-setup deps would be good, tracked by #2094. But it does not address this fundamental issue.

[mgsloan]

This approach seems to be working just fine. More control of installed cabal version is tracked by #2386 . Restricting cabal version is tracked by #2479