Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

Matthew,

I realize this to be a controversial issue, but what you're suggesting
is effectively an attempt at cutting this cabal V2 feature off at the knees
("If Cabal won't change its default let's cripple this feature on GHC's
side by rendering it pointless to use in cabal").

If ghc environment aren't read anymore by default they fail to have
the purpose they were invented for in the first place!

At the risk of repeating things I've tried to explain already in the
GitHub issue let me motivate (again) why we have these env files: We
want to be able to provide a stateful interface providing the common
idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
already provided in the past; e.g.


,----
| $ cabal v1-install lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| [1 of 1] ...
| ...
| 
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`----

or similarly, when you had just `cabal v1-build` something, you'd get
access to your projects dependencies which were installed into ghc's
user pkg-db.

This is also a workflow which has been well documented for over a decade
in Haskell's literature and instructions *and* this is the same idiom as
used by many popular package managers out there ("${pkgmgr} install
somelibrary")

So `cabal v1-build` made use of the user package-db facility to achieve
this; but now with `cabal v2-build` the goal was to improve this
workflow, but the user pkg-db facility wasn't a good fit anymore for the
nix-style pkg store cache which can easily have dozens instances for the
same lens-4.17 pkg-id cached (I just checked, I currently have 9
instances of `lens-4.17` cached in my GHC 8.4.4 pkg store).

So ghc environment files were born as a clever means to provide a
thinned slice/view into the nix-style pkg store.

And with these we can provide those workflows *without* the needed to pass
extra flags or having to prefix each `ghc` invocation with `cabal
repl`/`cabal exec`:

,----
| $ cabal v2-install --lib lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| [1 of 1] ...
| ...
|
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`----

(and respectively for the `cabal v2-build` workflow)

However, if we now had to explicitly pass a flag to ghc in order to have
it pick up ghc env files, this would severly break this workflow
everytime you forget about it, and it would certainly cause a lot of
confusion (of e.g. users following instructions such as `cabal install
lens` and then being confused that GHCi doesn't pick it up) and
therefore a worse user experience for cabal users.

Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6
have been picking up ghc env files by default (and finally we've reached
the point where the pkg-env-file-agnostic GHC versions are old enough to
have moved outside the traditional 3-5 major ghc release
support-windows!), and now you'd have to remember which GHC versions
don't do this anymore and instead require passing an additional
flag. This would IMO translate to a terrible user experience.

And also tooling would still need to have the logic to "isolate
themselves" for those versions of GHC that picked up env files by
default unless they dropped support for older versions. Also, how much
tooling is there even that needs to be aware of this and how did it cope
with GHC's user pkg db which can easily screw up things as well by
providing a weird enough pkg-db env! And why is it considered such a big
burden for tooling to invoke GHC in a robust enough way to not be
confused by the user's configuration? IMO, shifting the cost of passing
an extra flag to a tool which doesn't feel any pain is the better
tradeoff than to inconvience all cabal users to have rememeber to pass
an additional flag for what is designed to be the default UI/workflow
idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix
environment which already controls environment vars can easily override
GHC's or cabal's defaults to tailor them more towards Nix's specific
assumptions/requirements.


Long story short, I'm -1 on changing GHC's default as the resulting
downsides clearly outweight IMO.