<div dir="ltr"><div>I've also been surprised (not in a good way) by environment files. But I haven't followed all the discussion so I still have some questions.</div><div><br></div><div>As I understand it, the aim is to support workflows like "cabal install $pkg; ghci" (amongst other things). This currently works with 'cabal install' because it installs into the global package DB, but it doesn't work with 'cabal new-install' which installs into `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a .ghc-environment file in the current directory, even outside of a cabal package/project? I would find that *very* surprising as a user.</div><div><br></div><div>Indeed it almost works to say 'ghci -package-db ~/.cabal/store/ghc-8.4.3/package.db` after 'cabal new-install $pkg', but this might fail if there are conflicts in the package DB preventing the use of $pkg. GHC does some not-very-clever constraint solving to end up with a consistent set of packages, and you can guide it by adding '-package $pkg' flags. But it's still not very clever, and might fail.<br></div><div><br></div><div>Instead what if we had something like 'cabal ghci -package $pkg' to indicate that you want to start GHCi with $pkg available? It would be Cabal's job to ensure that $pkg was built and made available to GHCi. For more complex cases, you can create a package or a project, but simple ad-hoc invocations would be well supported by this.<br></div><div><br></div><div>I suppose I somewhat agree with those who are calling for environment files to require a command-line flag. We've gone to all this trouble to make a nice stateless model for the package DB, but then we've lobbed a stateful UI on top of it, which seems odd and is clearly surprising a lot of people.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com">hvriedel@gmail.com</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">Matthew,<br>
<br>
I realize this to be a controversial issue, but what you're suggesting<br>
is effectively an attempt at cutting this cabal V2 feature off at the knees<br>
("If Cabal won't change its default let's cripple this feature on GHC's<br>
side by rendering it pointless to use in cabal").<br>
<br>
If ghc environment aren't read anymore by default they fail to have<br>
the purpose they were invented for in the first place!<br>
<br>
At the risk of repeating things I've tried to explain already in the<br>
GitHub issue let me motivate (again) why we have these env files: We<br>
want to be able to provide a stateful interface providing the common<br>
idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`<br>
already provided in the past; e.g.<br>
<br>
<br>
,----<br>
| $ cabal v1-install lens lens-aeson<br>
| <br>
| $ ghc --make MyProgUsingLens.hs<br>
| [1 of 1] ...<br>
| ...<br>
| <br>
| $ ghci<br>
| GHCi, version 8.4.4: <a href="http://www.haskell.org/ghc/" rel="noreferrer" target="_blank">http://www.haskell.org/ghc/</a>  :? for help<br>
| Prelude> import Control.Lens<br>
| Prelude Control.Lens> <br>
`----<br>
<br>
or similarly, when you had just `cabal v1-build` something, you'd get<br>
access to your projects dependencies which were installed into ghc's<br>
user pkg-db.<br>
<br>
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")<br>
<br>
So `cabal v1-build` made use of the user package-db facility to achieve<br>
this; but now with `cabal v2-build` the goal was to improve this<br>
workflow, but the user pkg-db facility wasn't a good fit anymore for the<br>
nix-style pkg store cache which can easily have dozens instances for the<br>
same lens-4.17 pkg-id cached (I just checked, I currently have 9<br>
instances of `lens-4.17` cached in my GHC 8.4.4 pkg store).<br>
<br>
So ghc environment files were born as a clever means to provide a<br>
thinned slice/view into the nix-style pkg store.<br>
<br>
And with these we can provide those workflows *without* the needed to pass<br>
extra flags or having to prefix each `ghc` invocation with `cabal<br>
repl`/`cabal exec`:<br>
<br>
,----<br>
| $ cabal v2-install --lib lens lens-aeson<br>
| <br>
| $ ghc --make MyProgUsingLens.hs<br>
| Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default<br>
| [1 of 1] ...<br>
| ...<br>
|<br>
| $ ghci<br>
| GHCi, version 8.4.4: <a href="http://www.haskell.org/ghc/" rel="noreferrer" target="_blank">http://www.haskell.org/ghc/</a>  :? for help<br>
| Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default<br>
| Prelude> import Control.Lens<br>
| Prelude Control.Lens> <br>
`----<br>
<br>
(and respectively for the `cabal v2-build` workflow)<br>
<br>
However, if we now had to explicitly pass a flag to ghc in order to have<br>
it pick up ghc env files, this would severly break this workflow<br>
everytime you forget about it, and it would certainly cause a lot of<br>
confusion (of e.g. users following instructions such as `cabal install<br>
lens` and then being confused that GHCi doesn't pick it up) and<br>
therefore a worse user experience for cabal users.<br>
<br>
Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6<br>
have been picking up ghc env files by default (and finally we've reached<br>
the point where the pkg-env-file-agnostic GHC versions are old enough to<br>
have moved outside the traditional 3-5 major ghc release<br>
support-windows!), and now you'd have to remember which GHC versions<br>
don't do this anymore and instead require passing an additional<br>
flag. This would IMO translate to a terrible user experience.<br>
<br>
And also tooling would still need to have the logic to "isolate<br>
themselves" for those versions of GHC that picked up env files by<br>
default unless they dropped support for older versions. Also, how much<br>
tooling is there even that needs to be aware of this and how did it cope<br>
with GHC's user pkg db which can easily screw up things as well by<br>
providing a weird enough pkg-db env! And why is it considered such a big<br>
burden for tooling to invoke GHC in a robust enough way to not be<br>
confused by the user's configuration? IMO, shifting the cost of passing<br>
an extra flag to a tool which doesn't feel any pain is the better<br>
tradeoff than to inconvience all cabal users to have rememeber to pass<br>
an additional flag for what is designed to be the default UI/workflow<br>
idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix<br>
environment which already controls environment vars can easily override<br>
GHC's or cabal's defaults to tailor them more towards Nix's specific<br>
assumptions/requirements.<br>
<br>
<br>
Long story short, I'm -1 on changing GHC's default as the resulting<br>
downsides clearly outweight IMO.<br>
<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>