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

Should we avoid include newer versions of the Cabal library? #4425

Open
snoyberg opened this issue Mar 17, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@snoyberg
Copy link
Contributor

commented Mar 17, 2019

We had some discussions of this previously (I honestly don't remember where, I think on some PR). Essentially: including newer versions of the Cabal library is a good thing, in that users get improvements released since the version of Cabal shipped with GHC. And it's a bad thing, because it forces users to build a very heavy-weight library. I recently answered a Stack Overflow question about this:

https://stackoverflow.com/questions/55201279/stack-insists-on-building-cabal-package/55204058

Question: should we, by default, avoid including Cabal in snapshots and allow the global version to be included implicitly?

@DanBurton

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2019

This is a good question, and I don't see any "obviously right" answer.

On one hand, I theoretically prefer using the newer versions, and having good documentation about how to "opt out" (as demonstrated in that StackOverflow answer). It's true that there is a build cost to using newer versions of Cabal, but stack's dependency caching mechanisms at least make it so you don't have to pay that cost too often. The version of the world I want to see is one where builds of such common libraries are already cached by a trusted party for all relevant platforms, but alas, that is not yet the world we live in.

On the other hand, it seems extremely unlikely that users will ever actually need or even care about those improved Cabal versions. Users who do can pull them in easily. 99.99% of use cases are likely satisfied by using the Cabal that ships with GHC.

Locking Cabal to the GHC-shipped version, however, would also lock all of its dependencies (bytestring, text, containers). I think it's likely ok to do this, but we should always reserve the ability to depart from these versions for the sake of critical bugfixes and so forth.

@DanBurton

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2019

bytestring, containers and various others are already locked by the ghc package (until the "make the ghc package rebuildable" issue is fixed), so text is possibly the only relevant one to mention here.

@snoyberg

This comment has been minimized.

Copy link
Contributor Author

commented Mar 19, 2019

I think it's likely ok to do this, but we should always reserve the ability to depart from these versions for the sake of critical bugfixes and so forth.

I definitely agree here, we should always feel free to unpin if there's a strong motivation.

@snoyberg snoyberg referenced this issue Mar 31, 2019

Merged

Build GHC from source (#4567) #4655

3 of 3 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.