Proposal: Don't read environment files by default
Brandon Allbery
allbery.b at gmail.com
Fri Mar 29 03:44:14 UTC 2019
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> 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
--
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/fd214f8d/attachment.html>
More information about the ghc-devs
mailing list