Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vrom911 opened this issue Jan 5, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@vrom911
Copy link

commented Jan 5, 2019

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:

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:

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:

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

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

@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

This comment has been minimized.

Copy link
Author

commented Jan 6, 2019

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2019

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

snoyberg added a commit that referenced this issue Apr 3, 2019

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2019

See #4691

@snoyberg snoyberg closed this in eafecf5 Apr 3, 2019

snoyberg added a commit that referenced this issue Apr 3, 2019

Merge pull request #4691 from commercialhaskell/4488-respect-cabal-sp…
…ec-version

Respect cabal spec version (fixes #4488)

@chessai chessai referenced this issue Apr 4, 2019

Open

add nix and nixpkg scaffolding #283

4 of 6 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.