<div dir="ltr"><div>+1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the 
approach used by many other tools that handle this kind of thing. For 
example:</div><div>- nix-shell<br></div><div>- virtualenv</div><div>- rbenv</div><div>- sbt</div><div>- jenv</div><div><br></div><div>The
 advantage is that the scoping of the special configuration is very 
clear: it's the shell that the command launches. Programmers are very 
used to this, and changes in shell environments are expected to change 
the behaviour of programs.<br></div><div><br></div><div>Plus, as 
functional programmers this is just the sort of idiom we use all the 
time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.<br></div><div><br></div><div>On
 the negative side: I've helped ~6 people at my company alone debug 
issues due to environment files. Two of those were novice users (the 
people whom this feature is supposed to help). In my experience it 
breaks people's assumptions about what sort of things influence compiler
 invocations. People don't expect a stateful dependency from a previous 
run of a build tool to a later run of a lower-level compiler. Moreover, 
the failures can be mystifying, and I was only able to help because I 
already knew "get rid of any environment files" as a solution to "weird 
dependency issues".<br></div><div><br></div><div>*However*, I think 
Herbert is quite right that this particular proposal amounts to "remove 
this feature". The following might be a compromise solution: we can 
introduce `cabal ghc` as a parallel feature, and then in a few releases 
we can assess the popularity of the two approaches, and potentially stop
 generating environment files from Cabal if people aren't using them.</div><div><br></div><div>I
 think there are enough people that feel strongly about environment 
files that we could get together the manpower to write `cabal ghc`.</div><div><br></div><div>> This is also a workflow which has been well documented for over a decade<br>
in Haskell's literature and instructions *and* this is the same idiom as<br>
used by many popular package managers out there ("${pkgmgr} install<br>
somelibrary")</div><div><br></div><div>This is an interesting bit of 
background. FWIW, I would feel a lot better about this feature if it 
wasn't a side-effect of `cabal build`. If you had to run `cabal 
save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects`
 that wouldn't bother me (I still wouldn't use it, though). The current 
situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} 
install`, which is a bit surprising.<br></div><div><br></div><div>M</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 5:02 PM Bardur Arantsson <<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/03/2019 14.58, Oleg Grenrus wrote:<br>
> There is. Add<br>
> <br>
>     write-ghc-environment-files: never<br>
> <br>
> to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.<br>
> <br>
<br>
That doesn't really work if you actually want to be able to use both<br>
ways of working, does it? That same thing applies to<br>
<br>
  export GHC_ENVIRONMENT=-<br>
<br>
which someone else posted, but at least that can be done by tooling<br>
before invoking ghc. It's odd to have to change a global setting to<br>
avoid this. (However, thanks for the hints -- I'll be setting that<br>
GHC_ENVIRONMENT from now on.)<br>
<br>
+1 for changing the default.<br>
<br>
It seems really weird to force other tooling to opt out when this could<br>
easily be solved by just having<br>
<br>
   cabal ghci<br>
   cabal ghc<br>
<br>
commands which set up the environment properly and tell users to use<br>
that if they want to use cabal's environment files. FWIW, I also see<br>
e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas<br>
e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not<br>
something users should really be running unless they know what they're<br>
doing *and* it should be as tooling-friendly as possible.<br>
<br>
Regards,<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>