<div dir="ltr">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.<div><br></div><div>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 ghc does.</div><div><br></div><div>(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 anything about.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 13, 2018 at 4:53 AM, Wolfgang Jeltsch <span dir="ltr"><<a href="mailto:wolfgang-it@jeltsch.info" target="_blank">wolfgang-it@jeltsch.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am Samstag, den 12.05.2018, 16:41 -0400 schrieb Gershom B:<br>
> There is an important change in the cabal new- commands for 2.2 that<br>
> the release docs should have highlighted more significantly.<br>
> <br>
> Cabal new-* commands now produce a .ghc.environment file by default.<br>
> These files [1] are picked up by ghc and ghci automatically (since<br>
> 8.0.1), and allow them to operate directly with the same package<br>
> environment used by the new-* commands. This lets you, for example,<br>
> run `ghci` in a project where you are using `new-build` and get the<br>
> proper dependencies in scope. Herbert has written an experimental tool<br>
> to make it easier to create and manipulate these environments [2].<br>
<br>
</span>I already had issues with this. I ran some custom tool, which was a<br>
Haskell script, in a directory where I had run cabal new-build before.<br>
As a result, this tool didn’t work, because some module it needed<br>
couldn’t be found. It took me a while to find out what the problem was.<br>
<br>
In my opinion, it is questionable that these GHC environment files are<br>
generated by cabal new-build and then influence even Haskell scripts<br>
that have nothing to do with the project at hand.<br>
<br>
All the best,<br>
Wolfgang<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div>