haskell
Add a warning when an env file is created
Inspired by https://github.com/haskell/cabal/issues/6481#issuecomment-1934909998
I get that there are many colourable panels on the bikeshed that is cabal env, and even many real engineering choices and challenges, but it would be very nice if at least the user gets some warning if they cabal install --lib and that creates an environment file. After all, statistically, this is not what they intended, or if it was they probably didn't know the consequences. Had they known the consequences, they would have realised that this is not what they wanted.
This patch only shows a warning if an environment file does not yet exist, to acknowledge the set of people who are actually using this functionality.
This is blocked on the bug mentioned here: https://github.com/haskell/cabal/pull/9697#issuecomment-1938036790
- [x] Patches conform to the coding conventions.
- [ ] Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).
Thanks @Mikolaj and @fgaz! Very good suggestions, my PR was a bit premature perhaps.
I rebased the branch on the latest master, improved the warning message text, and added a check to only show the message if --package-env is not passed.
There is still this issue I found when testing this, but it feels unrelated.
How do you suggest I test this? A test should be self-contained so it cannot try to put a GHC environment file in the global environment, but making it local with --package-env disables the warning.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments suggests you can put the env file in the current directory (e.g., the directory created for the test) and also there's GHC_ENVIRONMENT.
@Mikolaj The point is that I'd like to test that cabal gives the warning at the appropriate time, i.e. when creating a new environment file without --package-env in effect. But in that situation, the environment file gets created globally (in ~/.ghc), which a test shouldn't do! Both because running tests shouldn't interfere with the machine it's running on, and because the tests shouldn't be impacted by whatever the contents of ~/.ghc happen to be on the testing machine. So I'm at a loss for how to test this PR :)
I see: you are interested in writing the file, not reading it. And it seems GHC_ENVIRONMENT doesn't override ~/.ghc, but adds to it, so it probably doesn't affect where things are written by cabal (I'm don't know).
I wonder how disastrous setting XDG_DATA_HOME to something fake would be...
I think the PR is ready, albeit without test. Good suggestions for a testing approach are welcome; merging as-is is also fine.
![mergify[bot] avatar](https://avatars.githubusercontent.com/in/10562?v=4 "Published by a pub.dev verified publisher"){kind=small}
I have tested this PR again when rebased to current master and it still works, so I guess it is ready for merging! :)
Great, it's going to merge in 2 days: https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#github-pull-request-conventions.
queue
🛑 The pull request has been removed from the queue default
The pull request can't be updated.
You can take a look at Queue: Embarked in merge queue check runs for more details.
In case of a failure due to a flaky test, you should first retrigger the CI.
Then, re-embark the pull request into the merge queue by posting the comment
@mergifyio refresh on the pull request.
Somehow the branch is not modifiable by mergify. I'm going to merge manually, since the delay has passed.
Huh, mergify merged automatically in the end after the CI finished after a mergify rebase. shrug
backport 3.12
✅ Backports have been created
-
#9895 Add a warning when an env file is created (backport #9705) has been created for branch
3.12