Proposal: Don't read environment files by default
duncan at well-typed.com
Thu Mar 28 18:22:12 UTC 2019
As one of the culprits who implemented this idea in ghc and cabal the
first place, I think that if it turns out this is just too surprising
for everyone then we should indeed change the default, and provide
another easy way to use it.
The intention of course is exactly what Iavor described:
> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty
> much always want it to load the environment associated with the
> project. It is incredibly useful when you are working on a project
> where there are multiple broken modules (e.g., during refactoring),
> and you want to fix them one at a time, in the order that makes sense
> to you.
The intention was to not force everyone to use "stack ghci" and "cabal
ghci" all the time, and for tutorials etc that just say "ghci" to
actually work. It's nice to be able to work with those tools directly.
Afterall, they're not that low level (like gcc); ghc/ghci have --make
functionality built in and can be used directly (i.e. without a ton of
But fair enough, there seems to be a very large number of users where
this behaviour is surprising, including reports I hear about the intro
Perhaps the next best thing is a "cabal shell" feature, that enters a
new system shell environment where ghc/ghci etc do pick up the project
This would rely on ghc continuing to use the environment variables to
select an package file, but we could disable ghc reading the files by
On Thu, 2019-03-28 at 10:08 +0000, Matthew Pickering wrote:
> Hi all,
> Environment files have caused a large amount of pain for users
> they are read by default by GHC.
> For example: https://github.com/haskell/cabal/issues/4542
> Cabal developers have indicated that they are not going to stop
> generating them by default despite the overwhelming user pressure.
> Therefore I propose that users should opt-in to using environment
> files by having to explicitly pass a flag to enable the search
> This will provide a much better user experience overall and will stop
> tooling having to isolate itself from their existence.
More information about the ghc-devs