<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I use cabal new-repl.<br>
<br>
I actually kind of like having GHC environment files (maybe not as
a default) but they remind me of "vim turds" in that they end up
littering your projects. <br>
<br>
Cheers,<br>
Vanessa McHale<br>
</p>
<div class="moz-cite-prefix">On 3/28/19 1:09 PM, Iavor Diatchki
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>