Nix instead of system, but roughly yes.
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@gmail.com
> <mailto:amindfv@gmail.com>> wrote:
>
>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
> <rae@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@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b@gmail.com <mailto:allbery.b@gmail.com>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--