<div dir="auto">> <span style="font-family:sans-serif;font-size:12.8px">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?</span><br><br>That's precisely how I use ghci. In quite a few of my use-cases all I care or want are the boot libraries and nothing else. I can appreciate that I may not be the common case here but I definitely use it this way. <div dir="auto"><br></div><div dir="auto">I'm agnostic on whether this change or not of reading the environment files by default. But I am very much against the cabal ghci or cabal ghc interfaces. It's one of the things I loathe the most about stack. I don't care what the compiler does by default on his own but I don't want to add another layer to the onion.</div><div dir="auto"><br></div><div dir="auto">I find this very hard to debug. Perhaps cabal should just ask you what you want the first time and that'll be your default. </div><div dir="auto"><br></div><div dir="auto">Tamar</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Sent from my Mobile</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019, 18:10 Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">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" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>