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

Closed
snoyberg opened this issue Mar 17, 2019 · 6 comments
Closed

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

snoyberg opened this issue Mar 17, 2019 · 6 comments

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg 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
Copy link
Contributor

@DanBurton DanBurton 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
Copy link
Contributor

@DanBurton DanBurton 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
Copy link
Contributor Author

@snoyberg snoyberg 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.

@juhp
Copy link
Contributor

@juhp juhp commented Mar 23, 2020

I think we are using ghc Cabal in recent Stackage streams?
Shall we close this out?

@qrilka
Copy link
Contributor

@qrilka qrilka commented Mar 23, 2020

If so then I suppose we should explicitly remove it from build-constraints and not only comment it out (as it is right now).

@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Mar 23, 2020

I prefer commented out: it makes it easier to see that it is intentionally excluded.

@snoyberg snoyberg closed this Mar 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants