Proposal: Don't read environment files by default

Oleg Grenrus oleg.grenrus at
Fri Mar 29 09:46:14 UTC 2019

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
> <mailto:amindfv at>> wrote:
>     > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>     <rae at> 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 <mailto:ghc-devs at>
> -- 
> brandon s allbery kf8nh
> allbery.b at <mailto:allbery.b at>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the ghc-devs mailing list