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 flags). 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 tutorial setting. 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 environment. 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 default. Thoughts? 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 because 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 behavior.
This will provide a much better user experience overall and will stop tooling having to isolate itself from their existence.