Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 18:33:58 +0000, Michael Peyton Jones wrote:
> +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used
> by many other tools that handle this kind of thing. For example:

..just because everyone else does it this way doesn't mean that it's the
best way.. I'd argue it might be a sign of lack of imagination  ;-)

In fact, personally I never liked `virtualenv` much as it required me

[...]

> The advantage is that the scoping of the special configuration is very
> clear: it's the shell that the command launches. Programmers are very used
> to this, and changes in shell environments are expected to change the
> behaviour of programs.

I'm a programmer. I'm very used to devel tooling I'm expected to invoke
as a programmer to be affected by what's in scope as a function of the CWD,
e.g. `cabal`, `git`, `make` to name a few.

And to me GHCi falls into the same category, it's a tool I'm expected to
interact directly with -- otherwisw it's CLI would be designed a lot
different; as a matter fact it's been supported for ages to pick up a
`.ghci` by walking up your fs system starting at CWD until one is found...
So there's clearly precedent for the logical next step that ghc env
files represent...

> Plus, as functional programmers this is just the sort of idiom we use all
> the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.

Sure, but then again, we're talking about the unix shell which leans
towards different idioms than the functional programming paradigm; and
insisting to impose one paradigm on a language which isn't rooted in
that paradigm is often not a good idea either...

> On the negative side: I've helped ~6 people at my company alone debug
> issues due to environment files.

Which GHC versions was this with?

[...]

> *However*, I think Herbert is quite right that this particular proposal
> amounts to "remove this feature". The following might be a compromise
> solution: we can introduce `cabal ghc` as a parallel feature, and then in a
> few releases we can assess the popularity of the two approaches, and
> potentially stop generating environment files from Cabal if people aren't
> using them.
>
> I think there are enough people that feel strongly about environment files
> that we could get together the manpower to write `cabal ghc`.

Sure, but this totally misses the point. We already have `cabal ghc` but
the point was (as Duncan also pointed out in an earlier reply) to *not*
have to require cabal as a middleman.

I want to be able to invoke `ghc` and `ghci` directly, without having to
invoke `cabal` everytime. If I wanted to always invoke `cabal ghci` I
wouldn't have needed to invest time to help with the ghc-env
feature... ;-)

>> 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")
>
> This is an interesting bit of background. FWIW, I would feel a lot better
> about this feature if it wasn't a side-effect of `cabal build`. If you had
> to run `cabal
> save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects`
> that wouldn't bother me (I still wouldn't use it, though). The current
> situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`,
> which is a bit surprising.

You can tweak your global cabal config to have `cabal` behave just like
that, i.e. then you'd have to explictly opt-in either by writing

  write-ghc-environment-files: always

into your current `cabal.project` configuration, or pass it adhoc on the
CLI

  cabal v2-build --write-ghc-environment-files=always

and as outlined earlier, the per-user env-files (which are picked up
when you are *not* in any project context) are already explicitly
managed (i.e. you have to explcitly invoke `cabal v2-install` to have
them be created/modified)


PS: There's two categories of pkg-env files (the per-HOME ones and the
    per-CWD ones) and I'm not sure if people are only complaining about
    the CWD ones or also the HOME ones...