Proposal: Don't read environment files by default

[Michael Peyton Jones]

+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:
- nix-shell
- virtualenv
- rbenv
- sbt
- jenv

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.

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

On the negative side: I've helped ~6 people at my company alone debug
issues due to environment files. Two of those were novice users (the people
whom this feature is supposed to help). In my experience it breaks people's
assumptions about what sort of things influence compiler invocations.
People don't expect a stateful dependency from a previous run of a build
tool to a later run of a lower-level compiler. Moreover, the failures can
be mystifying, and I was only able to help because I already knew "get rid
of any environment files" as a solution to "weird dependency issues".

*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`.

> 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.

M

On Thu, Mar 28, 2019 at 5:02 PM Bardur Arantsson <spam at scientician.net>
wrote:

> On 28/03/2019 14.58, Oleg Grenrus wrote:
> > There is. Add
> >
> >     write-ghc-environment-files: never
> >
> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
> >
>
> That doesn't really work if you actually want to be able to use both
> ways of working, does it? That same thing applies to
>
>   export GHC_ENVIRONMENT=-
>
> which someone else posted, but at least that can be done by tooling
> before invoking ghc. It's odd to have to change a global setting to
> avoid this. (However, thanks for the hints -- I'll be setting that
> GHC_ENVIRONMENT from now on.)
>
> +1 for changing the default.
>
> It seems really weird to force other tooling to opt out when this could
> easily be solved by just having
>
>    cabal ghci
>    cabal ghc
>
> commands which set up the environment properly and tell users to use
> that if they want to use cabal's environment files. FWIW, I also see
> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
> something users should really be running unless they know what they're
> doing *and* it should be as tooling-friendly as possible.
>
> Regards,
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/4b52f568/attachment.html>