On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus <oleg.gren...@iki.fi> wrote:
> > On 7.4.2019 17.21, Simon Marlow wrote: > > 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. > > This is not correct. Well, it was a question :) > Cabal doesn't write (local) .ghc.environment files > when you `cabal v2-install` __outside__ the project (actually it > doesn't, even when you `v2-install` the local project either, as you > don't build the local project then). > - When you install an executable, say `cabal v2-install alex` it do > nothing related to environment files (there is inference in reading them > atm though) > - When you install a library, say `cabal v2-install distributive --lib`, > then `cabal` (tries to) update > `~/.ghc/<arch>-<ghcver>/environments/default` (or specified > environment), so following > `ghci` or `(ghci -package-env=somename) could pickup that library. > Thanks, I wasn't aware of the default environment file. Seems perfectly reasonable to me. > Instead of cabal ghci -package $pkg you can do > > cabal v2-install $pkg1 --lib --package-env=foo > cabal v2-install $pkg2 --lib --package-env=foo > ... > ghci -package-env=foo > > Or alternatively > > cabal v2-repl -b $pkg > > Unfortunately neither way is (known) bug free at the moment. I mostly > use the former, with the `default` package-env (then I can omit > --package-env flags) for all kind of experiments, e.g. to try out things > when answering people on `#haskell` or Stack Overflow; but I have my own > way to create environment file (i.e. I don't use v2-install --lib), as > cabal is atm not perfect, see Cabal's issue 5888. It's however important > to note, that `cabal` makes `ghc` ignore these global environments > (especially the default one) in builds etc, so `cabal v2-build` works. > This all sounds good to me. I hope you can work out the bugs! Cheers Simon > 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. > > I disagree. I created `~/.ghci` and `~/.../environments/default` because > I want some defaults. Note: with v1-install people managed > user-package-db, with v2-install you are supposed to manage > environment(s). Yet, you can also only use `cabal v2-repl` or `cabal > v2-run` (See "new-run also supports running script files that ..." in > https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run > ). > > Most of the above works (sans known bugs), and if you run Ubuntu, I > invite you to try it out, as it's easy to install from Herbert's PPA: > https://launchpad.net/~hvr/+archive/ubuntu/ghc > > > > > Cheers > > Simon > > > > On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel > > <hvrie...@gmail.com <mailto:hvrie...@gmail.com>> wrote: > > > > Matthew, > > > > I realize this to be a controversial issue, but what you're > suggesting > > is effectively an attempt at cutting this cabal V2 feature off at > > the knees > > ("If Cabal won't change its default let's cripple this feature on > > GHC's > > side by rendering it pointless to use in cabal"). > > > > If ghc environment aren't read anymore by default they fail to have > > the purpose they were invented for in the first place! > > > > At the risk of repeating things I've tried to explain already in the > > GitHub issue let me motivate (again) why we have these env files: We > > want to be able to provide a stateful interface providing the common > > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` > > already provided in the past; e.g. > > > > > > ,---- > > | $ cabal v1-install lens lens-aeson > > | > > | $ ghc --make MyProgUsingLens.hs > > | [1 of 1] ... > > | ... > > | > > | $ ghci > > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > > | Prelude> import Control.Lens > > | Prelude Control.Lens> > > `---- > > > > or similarly, when you had just `cabal v1-build` something, you'd get > > access to your projects dependencies which were installed into ghc's > > user pkg-db. > > > > This is also a workflow which has been well documented for over a > > decade > > in Haskell's literature and instructions *and* this is the same > > idiom as > > used by many popular package managers out there ("${pkgmgr} install > > somelibrary") > > > > So `cabal v1-build` made use of the user package-db facility to > > achieve > > this; but now with `cabal v2-build` the goal was to improve this > > workflow, but the user pkg-db facility wasn't a good fit anymore > > for the > > nix-style pkg store cache which can easily have dozens instances > > for the > > same lens-4.17 pkg-id cached (I just checked, I currently have 9 > > instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). > > > > So ghc environment files were born as a clever means to provide a > > thinned slice/view into the nix-style pkg store. > > > > And with these we can provide those workflows *without* the needed > > to pass > > extra flags or having to prefix each `ghc` invocation with `cabal > > repl`/`cabal exec`: > > > > ,---- > > | $ cabal v2-install --lib lens lens-aeson > > | > > | $ ghc --make MyProgUsingLens.hs > > | Loaded package environment from > > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > > | [1 of 1] ... > > | ... > > | > > | $ ghci > > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > > | Loaded package environment from > > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > > | Prelude> import Control.Lens > > | Prelude Control.Lens> > > `---- > > > > (and respectively for the `cabal v2-build` workflow) > > > > However, if we now had to explicitly pass a flag to ghc in order > > to have > > it pick up ghc env files, this would severly break this workflow > > everytime you forget about it, and it would certainly cause a lot of > > confusion (of e.g. users following instructions such as `cabal > install > > lens` and then being confused that GHCi doesn't pick it up) and > > therefore a worse user experience for cabal users. > > > > Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and > > GHC 8.6 > > have been picking up ghc env files by default (and finally we've > > reached > > the point where the pkg-env-file-agnostic GHC versions are old > > enough to > > have moved outside the traditional 3-5 major ghc release > > support-windows!), and now you'd have to remember which GHC versions > > don't do this anymore and instead require passing an additional > > flag. This would IMO translate to a terrible user experience. > > > > And also tooling would still need to have the logic to "isolate > > themselves" for those versions of GHC that picked up env files by > > default unless they dropped support for older versions. Also, how > much > > tooling is there even that needs to be aware of this and how did > > it cope > > with GHC's user pkg db which can easily screw up things as well by > > providing a weird enough pkg-db env! And why is it considered such > > a big > > burden for tooling to invoke GHC in a robust enough way to not be > > confused by the user's configuration? IMO, shifting the cost of > > passing > > an extra flag to a tool which doesn't feel any pain is the better > > tradeoff than to inconvience all cabal users to have rememeber to > pass > > an additional flag for what is designed to be the default UI/workflow > > idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, > > the Nix > > environment which already controls environment vars can easily > > override > > GHC's or cabal's defaults to tailor them more towards Nix's specific > > assumptions/requirements. > > > > > > Long story short, I'm -1 on changing GHC's default as the resulting > > downsides clearly outweight IMO. > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
