Proposal: Don't read environment files by default

Mon Apr 8 07:19:58 UTC 2019

On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus <oleg.grenrus at 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
> > <hvriedel at gmail.com <mailto:hvriedel at 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 at haskell.org <mailto:ghc-devs at haskell.org>
> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190408/cedddbde/attachment.html>