<div dir="ltr">I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal").   When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want.   What is the workflow that this proposal optimizes?<div><br></div><div><div>The default behavior should be what's commonly useful and, in my experience, when I run GHCi in the context of a project, I pretty much always want it to load the environment associated with the project.   It is incredibly useful when you are working on a project where there are multiple broken modules (e.g., during refactoring), and you want to fix them one at a time, in the order that makes sense to you.</div><div><br></div><div>-Iavor<br><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson <<a href="mailto:spam@scientician.net">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>