<div dir="ltr"><div dir="ltr">On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi">oleg.grenrus@iki.fi</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 7.4.2019 17.21, Simon Marlow wrote:<br>> As I understand it, the aim is to support workflows like "cabal<br>
> install $pkg; ghci" (amongst other things). This currently works with<br>
> 'cabal install' because it installs into the global package DB, but it<br>
> doesn't work with 'cabal new-install' which installs into<br>
> `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a<br>
> .ghc-environment file in the current directory, even outside of a<br>
> cabal package/project? I would find that *very* surprising as a user.<br>
<br>
This is not correct. </blockquote><div><br></div><div>Well, it was a question :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cabal doesn't write (local) .ghc.environment files<br>
when you `cabal v2-install` __outside__ the project (actually it<br>
doesn't, even when you `v2-install` the local project either, as you<br>
don't build the local project then).<br>
- When you install an executable, say `cabal v2-install alex` it do<br>
nothing related to environment files (there is inference in reading them<br>
atm though)<br>
- When you install a library, say `cabal v2-install distributive --lib`,<br>
then `cabal` (tries to) update<br>
`~/.ghc/<arch>-<ghcver>/environments/default` (or specified<br>
environment), so following<br>
`ghci` or `(ghci -package-env=somename) could pickup that library.<br></blockquote><div><br></div><div>Thanks, I wasn't aware of the default environment file. Seems perfectly reasonable to me.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Instead of cabal ghci -package $pkg you can do<br>
<br>
    cabal v2-install $pkg1 --lib --package-env=foo<br>
    cabal v2-install $pkg2 --lib --package-env=foo<br>
    ...<br>
    ghci -package-env=foo<br>
<br>
Or alternatively<br>
<br>
    cabal v2-repl -b $pkg<br>
<br>
Unfortunately neither way is (known) bug free at the moment. I mostly<br>
use the former, with the `default` package-env (then I can omit<br>
--package-env flags) for all kind of experiments, e.g. to try out things<br>
when answering people on `#haskell` or Stack Overflow; but I have my own<br>
way to create environment file (i.e. I don't use v2-install --lib), as<br>
cabal is atm not perfect, see Cabal's issue 5888. It's however important<br>
to note, that `cabal` makes `ghc` ignore these global environments<br>
(especially the default one) in builds etc, so `cabal v2-build` works.<br></blockquote><div><br></div><div>This all sounds good to me. I hope you can work out the bugs!<br></div></div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I suppose I somewhat agree with those who are calling for environment<br>
> files to require a command-line flag. We've gone to all this trouble<br>
> to make a nice stateless model for the package DB, but then we've<br>
> lobbed a stateful UI on top of it, which seems odd and is clearly<br>
> surprising a lot of people.<br>
<br>
I disagree. I created `~/.ghci` and `~/.../environments/default` because<br>
I want some defaults. Note: with v1-install people managed<br>
user-package-db, with v2-install you are supposed to manage<br>
environment(s). Yet, you can also only use `cabal v2-repl` or `cabal<br>
v2-run` (See "new-run also supports running script files that ..." in<br>
<a href="https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run" rel="noreferrer" target="_blank">https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run</a>).<br>
<br>
Most of the above works (sans known bugs), and if you run Ubuntu, I<br>
invite you to try it out, as it's easy to install from Herbert's PPA:<br>
<a href="https://launchpad.net/~hvr/+archive/ubuntu/ghc" rel="noreferrer" target="_blank">https://launchpad.net/~hvr/+archive/ubuntu/ghc</a><br>
<br>
><br>
> Cheers<br>
> Simon<br>
><br>
> On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel<br>
> <<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a> <mailto:<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>>> wrote:<br>
><br>
>     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<br>
>     the knees<br>
>     ("If Cabal won't change its default let's cripple this feature on<br>
>     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<br>
>     decade<br>
>     in Haskell's literature and instructions *and* this is the same<br>
>     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<br>
>     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<br>
>     for the<br>
>     nix-style pkg store cache which can easily have dozens instances<br>
>     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<br>
>     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<br>
>     /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<br>
>     /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<br>
>     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<br>
>     GHC 8.6<br>
>     have been picking up ghc env files by default (and finally we've<br>
>     reached<br>
>     the point where the pkg-env-file-agnostic GHC versions are old<br>
>     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<br>
>     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<br>
>     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<br>
>     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,<br>
>     the Nix<br>
>     environment which already controls environment vars can easily<br>
>     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> <mailto:<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>
><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>
<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>