cabal
cabal copied to clipboard
`cabal install --lib` on `master` always brings `base` into scope
Describe the bug
I just noticed that package environments created with cabal-3.10.2.1
always bring base
into scope.
- Is this a bug, or intentional?
- If intentional, what is the rational?
- Is there a way to prevent this, reverting to the
cabal-3.10.2.1
behavior?
To Reproduce
$ cabal-3.10.2.1 install --package-env=foo.env --lib relude && cat foo.env
package-db /home/sol/.local/state/cabal/store/ghc-9.8.1/package.db
package-id base-4.19.0.0-c1f2
package-id relude-1.2.1.0-99ccbd1e31593ddccbc7a9d9260492b913d75dae58e3f7684fb550a45d957235
vs
$ cabal-3.10.1.0 install --package-env=foo.env --lib relude && cat foo.env
clear-package-db
global-package-db
package-db /home/sol/.local/state/cabal/store/ghc-9.8.1/package.db
package-id relude-1.2.1.0-99ccbd1e31593ddccbc7a9d9260492b913d75dae58e3f7684fb550a45d957235
intentional: https://github.com/haskell/cabal/pull/8903
ticket with discussion here: https://github.com/haskell/cabal/issues/8894
Is there a reason you don't want base added, btw?
Is there a reason you don't want base added, btw?
https://gitlab.haskell.org/ghc/ghc/-/issues/24399
Thanks @gbaz.
intentional: https://github.com/haskell/cabal/pull/8903
That's unfortunate.
My understanding is that environment files are meant to precisely control the environment (read: what exact packages are in scope).
With 3.10.1.0
I think it was easy to add base
explicitly, if desired by the user.
On the other hand, with 3.10.2.1
, is there a way to explicitly ask cabal
to not add base
?
On the other hand, with 3.10.2.1, is there a way to explicitly ask cabal to not add base?
Unfortunately not. It should be easy enough to remove base
by hand, should you so desire, although that's not the most pleasant workflow.
As the linked tickets show, most people want base most of the time, and there was a lot of frustration (only some reflected on the ticket) when this was removed as part of a broader cleanup. (Before, cabal had also added a lot of other stuff too). I imagine a pr for a flag would be welcomed, to add an explicit mechanism for users who want it.
I was one of those who argued for inclusion of base
by default but I find sol's argument convincing now. Can we have the cake and eat it too? There may be two ways forward (besides simply reverting):
-
revert the change and think how to guide the users who missed
base
unintentionally by carefully crafting a new warning; -
leave the change but add a flag like
--no-base
which doesn't addbase
.