[Haskell-cafe] PSA for Cabal 2.2 new-* users regarding .ghc.environment files
allbery.b at gmail.com
Sun May 13 09:39:17 UTC 2018
The whole point of them is to enable doing things that no tooling can
sanely automate, enabling the environment from those builds to be available
to do those things. Which is admittedly trying to do two incompatible
things at once (propagate the build environment sometimes but not always,
with no way to know which is intended); if you have a good answer for that
one, I suspect many people would like to hear it.
Stack has this a bit easier in that it can just expose its own environment,
but it's also by design and intent less flexible than cabal new-build:
reproducible builds means a static, predefined environment instead of the
dynamic but constrained one presented by cabal new-build. Each tool has its
own purpose and use cases; but while cabal new-build can produce frozen
configurations emulating stack, there's no reasonable way to get a dynamic
configuration from stack. The flip side of which is you need those
environment files to get access to new-build's current/latest environment.
It's definitely "wrong solution", but nobody has been able to figure out
what the right solution is yet, or at least not in a way that works the way
(Which points to the further issue that how ghc works is itself rather
limiting, thus stack and cabal trying to impose alternative solutions on
it. But changing that is an even more tangled hairball, starting with "what
exactly do you change it to?". Which might not have the same answer for
stack vs. cabal, to say nothing of other build tools that might be in use
e.g. in corporate in-house programming and that nobody outside them knows
On Sun, May 13, 2018 at 4:53 AM, Wolfgang Jeltsch <wolfgang-it at jeltsch.info>
> Am Samstag, den 12.05.2018, 16:41 -0400 schrieb Gershom B:
> > There is an important change in the cabal new- commands for 2.2 that
> > the release docs should have highlighted more significantly.
> > Cabal new-* commands now produce a .ghc.environment file by default.
> > These files  are picked up by ghc and ghci automatically (since
> > 8.0.1), and allow them to operate directly with the same package
> > environment used by the new-* commands. This lets you, for example,
> > run `ghci` in a project where you are using `new-build` and get the
> > proper dependencies in scope. Herbert has written an experimental tool
> > to make it easier to create and manipulate these environments .
> I already had issues with this. I ran some custom tool, which was a
> Haskell script, in a directory where I had run cabal new-build before.
> As a result, this tool didn’t work, because some module it needed
> couldn’t be found. It took me a while to find out what the problem was.
> In my opinion, it is questionable that these GHC environment files are
> generated by cabal new-build and then influence even Haskell scripts
> that have nothing to do with the project at hand.
> All the best,
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
brandon s allbery kf8nh sine nomine associates
allbery.b at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe