Proposal: Don't read environment files by default

[Matthew Pickering]

Thanks everyone for the lively discussion last week. I think we all
understand better now about environment files.

GHC reading environment files by default doesn't seem to be a problem
as it is just like having more packages installed in the global
package DB. This could be convenient.

The largest issue with the files is that cabal places relative paths
into the environment files which can easily become stale. For example,
by deleting the dist-newstyle directory. The absolute paths can also
become stale (as Richard discovered).

Therefore, it seems the correct course of action is to stop cabal
generating the environment files by default. If user's still want to
use them then they are easy to enable globally via a configuration
setting.

This can be achieved by adding the following to your "~/.cabal/config" file:

write-ghc-environment-files: always

The patch which changes the default behavior is here:

https://github.com/haskell/cabal/pull/5985

Cheers,

Matt

On Fri, Mar 29, 2019 at 4:53 PM Brandon Allbery <allbery.b at gmail.com> wrote:
>
> Nix instead of system, but roughly yes.
>
> On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>>
>> To clarify: You mean different installations of same-version GHC? E.g.
>> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
>> both happen to be 8.4.4 (so some other version)?
>>
>> - Oleg
>>
>> On 29.3.2019 5.44, Brandon Allbery wrote:
>> > FWIW I've run into this one myself, and use (clones, if necessary, of)
>> > v1 sandboxes for it currently.
>> >
>> > I've also been both bitten by, and helped by, environment files. The
>> > former is somewhat nastier, especially if you have multiple versions
>> > of ghc around and a given environment file was generated by a
>> > different ghc.
>> >
>> > I also have a somewhat weird setup, because of how I ended up cobbling
>> > this machine together: the global and user package dbs for my default
>> > ghc are more or less "owned" by xmonad development, anything else is
>> > in v2, a sandbox, or otherwise a different ghc version. Including nix,
>> > also operating as a sandbox (that is, I use an alias to set up nix
>> > within specific shells, rather than unconditionally loading its
>> > config). Plus that "default ghc" is via wrappers around hvr's ghc
>> > repos for Ubuntu. Which means I have lots of different ghcs around,
>> > depending on which shell window I'm in. Not that I'm expecting anyone
>> > to directly support this mess, but environment files seem to play
>> > especially badly with multiple ghc versions with different packages
>> > installed.
>> >
>> > On Thu, Mar 28, 2019 at 11:33 PM <amindfv at gmail.com
>> > <mailto:amindfv at gmail.com>> wrote:
>> >
>> >
>> >     > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>> >     <rae at richarde.dev> escribió:
>> >     >
>> >
>> >     [...]
>> >
>> >     > 2. I get pilloried every time I say it, but I vastly prefer
>> >     global package databases to local ones.
>> >
>> >     I'll second this in one specific context. v2-build has been
>> >     amazing at work and in general for project-based development, but
>> >     – and maybe simply because I don't know the right incantations – a
>> >     step backwards for impromptu coding where I don't want to set up a
>> >     whole project to start messing with an idea.
>> >
>> >     I've actually fallen back to v1-install for this specific usecase:
>> >     I have a set of ~15 packages, all installed from local git repos,
>> >     some of which depend on others, that I *always* want when I'm in
>> >     GHCi. It's basically my base. I may simply be doing it wrong but
>> >     I've been unable to use the "global ghc.env file" trick successfully.
>> >
>> >     Tom
>> >     _______________________________________________
>> >     ghc-devs mailing list
>> >     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> >
>> > --
>> > brandon s allbery kf8nh
>> > allbery.b at gmail.com <mailto:allbery.b at gmail.com>
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs