Skip to content

cabal install --lib on master always brings base into scope #9672

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

Open
sol opened this issue Jan 30, 2024 · 9 comments
Open

cabal install --lib on master always brings base into scope #9672

sol opened this issue Jan 30, 2024 · 9 comments

Comments

@sol
Copy link
Member

sol commented Jan 30, 2024

Describe the bug
I just noticed that package environments created with cabal-3.10.2.1 always bring base into scope.

  1. Is this a bug, or intentional?
  2. If intentional, what is the rational?
  3. 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
@gbaz
Copy link
Collaborator

gbaz commented Jan 30, 2024

intentional: #8903

ticket with discussion here: #8894

@gbaz
Copy link
Collaborator

gbaz commented Jan 30, 2024

Is there a reason you don't want base added, btw?

@sol
Copy link
Member Author

sol commented Jan 31, 2024

Is there a reason you don't want base added, btw?

https://gitlab.haskell.org/ghc/ghc/-/issues/24399

@sol
Copy link
Member Author

sol commented Jan 31, 2024

Thanks @gbaz.

intentional: #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?

@gbaz
Copy link
Collaborator

gbaz commented Feb 1, 2024

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.

@ulysses4ever ulysses4ever changed the title Regression vs 3.10.1.0 cabal install --lib on master always bring base into scope Mar 1, 2024
@ulysses4ever ulysses4ever changed the title cabal install --lib on master always bring base into scope cabal install --lib on master always brings base into scope Mar 1, 2024
@ulysses4ever
Copy link
Collaborator

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 add base.

@tomsmeding
Copy link
Collaborator

I vote for the second option (--no-base).

The Haskell ecosystem as a whole largely assumes one uses base. Similarly, it largely assumes that one uses Prelude. For the latter, if you don't want that, we have -XNoImplicitPrelude. Similarly, I would argue that the --no-base option makes the most sense. If you want non-standard behaviour, add a flag; people who want the expected thing should pass fewer flags.

@ulysses4ever
Copy link
Collaborator

Totally agree with Tom on this one. Shouldn't be hard to implement.

@sol
Copy link
Member Author

sol commented Jul 12, 2024

Works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants