Proposal: Don't read environment files by default

Sun Apr 7 15:57:07 UTC 2019

On 7.4.2019 17.21, Simon Marlow wrote:
> 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.
>
> 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. 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.

For playing with libraries, you can manage multiple environments, and
starting over (as you will eventually run into incompatible package
versions) isn't as expensive, as packages are still cached in store.
This is however a goal, and not yet a reality, due to bugs in cabal: see
e.g https://github.com/haskell/cabal/issues/5888 and
https://github.com/haskell/cabal/issues/5559 issues.

>
> 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.
>
> 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.
>
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.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190407/126aff4f/attachment.sig>