Proposal: Don't read environment files by default

[Simon Marlow]

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.

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.

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.

Cheers
Simon

On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel <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
> 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/20190407/42bcd57b/attachment.html>