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.

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.

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@gmail.com <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