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
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 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs