Re: Proposal: Don't read environment files by default

On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus 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 mailto:hvriedel@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