How to use stack with newer cabal version for older GHC?

[vrom911]

Problem

As far as I see Stack LTS not only determine the version of GHC, but also restricted to use only the specific Cabal version that is stuck with the particular GHC. This creates some problems with using a unique version of Cabal for different versions of GHCs, for example, using common stanzas in cabal file with cabal: 2.4 and support both GHC-8.6.3 and GHC-8.4.4.

Stack also doesn't allow and deprecates now options: --install-cabal and --upgrade-cabal.

The question is: how is it possible to use a newer version of Cabal (eg. 2.4) for the old GHCs (e.g. 8.0.2)?

Example

I've created a test project to illustrate the problem clearer. It can be found here:

• https://github.com/vrom911/summon-test

I want to support GHC versions:

• 8.0.2
• 8.2.2
• 8.4.4
• 8.6.3

To assure that everything works at all versions both with Stack and Cabal I've created this Travis file:

• https://github.com/vrom911/summon-test/blob/6ac63c3ad672d24b6f61589cdd163d33a5e2d64a/.travis.yml

where I explicitly specify - cabal: 2.0.

Though it's ignored, so I also added this if statement (which is apparently doesn't work either):

https://github.com/vrom911/summon-test/blob/6ac63c3ad672d24b6f61589cdd163d33a5e2d64a/.travis.yml#L42-L44

And here is the output of failing Travis job for GHC-8.0.2 can be found here:

• https://travis-ci.org/vrom911/summon-test/jobs/475464765

Stack version

Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1

Method of installation

curl -sSL https://get.haskellstack.org/ | sh

[snoyberg]

Have you tried adding Cabal as an extra-deps entry? I'm not sure if it will be used for build-type: Simple or not, but it's certainly possible for us to add a configuration option to Stack to force the newer Cabal library version to be used. The tradeoff is that it will force the (really CPU and memory intensive) build of Cabal before anything else can be built. But that sounds like exactly what you want here.

[qrilka]

@snoyberg I had a quick look into this yesterday and it looks like out of the box extra-deps will not work as Stack uses Cabal version from global package database - https://github.com/commercialhaskell/stack/blob/stable/src/Stack/GhcPkg.hs#L176

[vrom911]

Yes, this is true. I tried with extra-deps and I still have the same error..

[snoyberg]

Would it work for your use case to have an option to force specific packages, or even all local packages, to be treated as custom build types and therefore build against the snapshot's Cabal library? The difficult problem with compiling all packages with this new Cabal version is cyclic dependencies.

[vrom911]

I don't quite get this solution, sorry.. My problem is in running a fixed Cabal version with different GHCs at CI, so I don't quite have the control on local packages there. Could you please clarify this a bit?

[snoyberg]

When you use a build-type: Custom in a package, then its Setup.hs is built against the snapshot's Cabal library version, not the global one that ships with GHC. In theory, setting built-type: Custom would seem to achieve what you're looking for. I'm wondering if adding an option to stack.yaml to treat a specific package that way would address your concern.

[snoyberg]

Actually, on second thought, this may be more easily detectable via comparing the cabal-version field. I'll consider this...