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

On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus 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 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

I am +1 on not reading them by default. I dislike implicit configuration (that's enough reason there), and it interacts poorly with other tools that use ghc. Like Richard Eisenberg, I also think of ghc as a low-level utility, but I recognize that intuition is already wrong in various ways. (ghc is really quite clever.) For me that's not reason enough to disable this. The tight coupling with Cabal, however, seems unwise, and implicit configuration seems like something from the 20th century. If we want Nix-style builds, let's do them Nix style, and use a shell. On Thu, Mar 28, 2019 at 3:50 PM Richard Eisenberg wrote:

I have spent quite a bit of time debugging this issue, being utterly surprised about the existence of these files. Furthermore, until today, I had been unable to find a way to turn the feature off. I now understand ( https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented mechanism for doing so in GHC. It's still frustrating that there is no similar mechanism to globally (i.e., in ~/.cabal/config) disable these files in cabal.

While I expect "project-based" tools to care about their directory (e.g., git, cabal, stack), I would never expect a compiler (which is intended to be a low-level utility) to do so.

Richard

...

On Mar 28, 2019, at 6:08 AM, Matthew Pickering < matthewtpickering@gmail.com> wrote:

Hi all,

Environment files have caused a large amount of pain for users because they are read by default by GHC.

For example: https://github.com/haskell/cabal/issues/4542

Cabal developers have indicated that they are not going to stop generating them by default despite the overwhelming user pressure.

Therefore I propose that users should opt-in to using environment files by having to explicitly pass a flag to enable the search behavior.

This will provide a much better user experience overall and will stop tooling having to isolate itself from their existence.

Cheers,

Matt _______________________________________________ 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

On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel wrote:

I for one would hate to remove what I consider a useful feature

I don't see anyone is asking for a feature removal here. This thread seems to be more about how to set a default. I personally find it surprising for a tool like a compiler to be directory-sensitive. But I've now learned that with `export GHC_ENVIRONMENT=-` in my profile, my compiler indeed isn't directory-sensitive. Furthermore, I've learned how to suppress the env files entirely with `write-ghc-environment-files: never` in my ~/.cabal/config. So I'm not actually all too bothered by this anymore. I retain my opinion that directory-sensitivity is a poor design (it's precisely what threw me off Stack the first time I tried it) for compiler-like tools, but perhaps that ship has sailed, as I agree that changing this now may lead to a poor user experience. Richard

There is. Add     write-ghc-environment-files: never to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. - Oleg On 28.3.2019 15.49, Richard Eisenberg wrote:

I have spent quite a bit of time debugging this issue, being utterly surprised about the existence of these files. Furthermore, until today, I had been unable to find a way to turn the feature off. I now understand (https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented mechanism for doing so in GHC. It's still frustrating that there is no similar mechanism to globally (i.e., in ~/.cabal/config) disable these files in cabal.

While I expect "project-based" tools to care about their directory (e.g., git, cabal, stack), I would never expect a compiler (which is intended to be a low-level utility) to do so.

Richard

...

On Mar 28, 2019, at 6:08 AM, Matthew Pickering wrote:

Hi all,

Environment files have caused a large amount of pain for users because they are read by default by GHC.

For example: https://github.com/haskell/cabal/issues/4542

Cabal developers have indicated that they are not going to stop generating them by default despite the overwhelming user pressure.

Therefore I propose that users should opt-in to using environment files by having to explicitly pass a flag to enable the search behavior.

This will provide a much better user experience overall and will stop tooling having to isolate itself from their existence.

Cheers,

Matt _______________________________________________ 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

I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want. What is the workflow that this proposal optimizes? The default behavior should be what's commonly useful and, in my experience, when I run GHCi in the context of a project, I pretty much always want it to load the environment associated with the project. It is incredibly useful when you are working on a project where there are multiple broken modules (e.g., during refactoring), and you want to fix them one at a time, in the order that makes sense to you. -Iavor On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson wrote:

On 28/03/2019 14.58, Oleg Grenrus wrote:

...

There is. Add

write-ghc-environment-files: never

to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.

That doesn't really work if you actually want to be able to use both ways of working, does it? That same thing applies to

export GHC_ENVIRONMENT=-

which someone else posted, but at least that can be done by tooling before invoking ghc. It's odd to have to change a global setting to avoid this. (However, thanks for the hints -- I'll be setting that GHC_ENVIRONMENT from now on.)

+1 for changing the default.

It seems really weird to force other tooling to opt out when this could easily be solved by just having

cabal ghci cabal ghc

commands which set up the environment properly and tell users to use that if they want to use cabal's environment files. FWIW, I also see e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not something users should really be running unless they know what they're doing *and* it should be as tooling-friendly as possible.

Regards,

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want. What is the workflow that this proposal optimizes?

That's precisely how I use ghci. In quite a few of my use-cases all I care or want are the boot libraries and nothing else. I can appreciate that I may not be the common case here but I definitely use it this way. I'm agnostic on whether this change or not of reading the environment files by default. But I am very much against the cabal ghci or cabal ghc interfaces. It's one of the things I loathe the most about stack. I don't care what the compiler does by default on his own but I don't want to add another layer to the onion. I find this very hard to debug. Perhaps cabal should just ask you what you want the first time and that'll be your default. Tamar Sent from my Mobile On Thu, Mar 28, 2019, 18:10 Iavor Diatchki wrote:

I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want. What is the workflow that this proposal optimizes?

The default behavior should be what's commonly useful and, in my experience, when I run GHCi in the context of a project, I pretty much always want it to load the environment associated with the project. It is incredibly useful when you are working on a project where there are multiple broken modules (e.g., during refactoring), and you want to fix them one at a time, in the order that makes sense to you.

-Iavor

On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson wrote:

...

On 28/03/2019 14.58, Oleg Grenrus wrote:

...

There is. Add

write-ghc-environment-files: never

to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.

That doesn't really work if you actually want to be able to use both ways of working, does it? That same thing applies to

export GHC_ENVIRONMENT=-

which someone else posted, but at least that can be done by tooling before invoking ghc. It's odd to have to change a global setting to avoid this. (However, thanks for the hints -- I'll be setting that GHC_ENVIRONMENT from now on.)

+1 for changing the default.

It seems really weird to force other tooling to opt out when this could easily be solved by just having

cabal ghci cabal ghc

commands which set up the environment properly and tell users to use that if they want to use cabal's environment files. FWIW, I also see e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not something users should really be running unless they know what they're doing *and* it should be as tooling-friendly as possible.

Regards,

_______________________________________________ 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

On 2019-03-28 at 18:33:58 +0000, Michael Peyton Jones wrote:

+1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used by many other tools that handle this kind of thing. For example:

..just because everyone else does it this way doesn't mean that it's the best way.. I'd argue it might be a sign of lack of imagination ;-) In fact, personally I never liked `virtualenv` much as it required me [...]

The advantage is that the scoping of the special configuration is very clear: it's the shell that the command launches. Programmers are very used to this, and changes in shell environments are expected to change the behaviour of programs.

I'm a programmer. I'm very used to devel tooling I'm expected to invoke as a programmer to be affected by what's in scope as a function of the CWD, e.g. `cabal`, `git`, `make` to name a few. And to me GHCi falls into the same category, it's a tool I'm expected to interact directly with -- otherwisw it's CLI would be designed a lot different; as a matter fact it's been supported for ages to pick up a `.ghci` by walking up your fs system starting at CWD until one is found... So there's clearly precedent for the logical next step that ghc env files represent...

Plus, as functional programmers this is just the sort of idiom we use all the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.

Sure, but then again, we're talking about the unix shell which leans towards different idioms than the functional programming paradigm; and insisting to impose one paradigm on a language which isn't rooted in that paradigm is often not a good idea either...

On the negative side: I've helped ~6 people at my company alone debug issues due to environment files.

Which GHC versions was this with? [...]

*However*, I think Herbert is quite right that this particular proposal amounts to "remove this feature". The following might be a compromise solution: we can introduce `cabal ghc` as a parallel feature, and then in a few releases we can assess the popularity of the two approaches, and potentially stop generating environment files from Cabal if people aren't using them.

I think there are enough people that feel strongly about environment files that we could get together the manpower to write `cabal ghc`.

Sure, but this totally misses the point. We already have `cabal ghc` but the point was (as Duncan also pointed out in an earlier reply) to *not* have to require cabal as a middleman. I want to be able to invoke `ghc` and `ghci` directly, without having to invoke `cabal` everytime. If I wanted to always invoke `cabal ghci` I wouldn't have needed to invest time to help with the ghc-env feature... ;-)

...

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")

This is an interesting bit of background. FWIW, I would feel a lot better about this feature if it wasn't a side-effect of `cabal build`. If you had to run `cabal save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects` that wouldn't bother me (I still wouldn't use it, though). The current situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`, which is a bit surprising.

You can tweak your global cabal config to have `cabal` behave just like that, i.e. then you'd have to explictly opt-in either by writing write-ghc-environment-files: always into your current `cabal.project` configuration, or pass it adhoc on the CLI cabal v2-build --write-ghc-environment-files=always and as outlined earlier, the per-user env-files (which are picked up when you are *not* in any project context) are already explicitly managed (i.e. you have to explcitly invoke `cabal v2-install` to have them be created/modified) PS: There's two categories of pkg-env files (the per-HOME ones and the per-CWD ones) and I'm not sure if people are only complaining about the CWD ones or also the HOME ones...

Hi Herbert, On Thu, Mar 28, 2019 at 08:33:41PM +0100, Herbert Valerio Riedel wrote:

I'm a programmer. I'm very used to devel tooling I'm expected to invoke as a programmer to be affected by what's in scope as a function of the CWD, e.g. `cabal`, `git`, `make` to name a few.

I think the difference here is, that tools like 'git' create and use the environment by themselves. So it's IMHO a lot easier to get an intuition about the behaviour of these tools. That's not the case for 'cabal' creating an environment and 'ghc' using it. Greetings, Daniel

On 2019-03-28 at 18:22:12 +0000, Duncan Coutts wrote:

The intention was to not force everyone to use "stack ghci" and "cabal ghci" all the time,

And it's important to note that those who *want* to be forced to "cabal ghci" all the time, can still subject themselves to that idiom by configuring their cabal installation accordingly. However, the point here is that there's also those of us who don't want to be denied the ability to *not* be forced to use that idiom, and instead use the CWD-sensitive idiom which nobody complains about when using Git or make. With GHC/Cabal as it stands we are ahead of other ecosystems as we're in the advantageous position to be able to support *more* workflows than other ecosystems can support. IMO we should embrace and leverage the flexibility rather than to trying to artificially limit our possibilities just because we're doing something different. I mean, with that attitude we can just stop trying to do anything new... ;-)

Perhaps the next best thing is a "cabal shell" feature, that enters a new system shell environment where ghc/ghci etc do pick up the project environment.

We already have this don't we? That's basically what `cabal v2-exec` does; but having to remember to invoke `cabal v2-exec bash` to enter a sub-shell is basically just a variant of "force everyone to use "cabal ghci" all the time where you have to go through cabal as a middleman even though you shouldn't have to. Don't get me wrong, it's good that we have `cabal v2-exec` as yet another tool in our toolbox and it can do a few extra things in that workflow and is useful for those who have opt-ed out of the automatic per-project CWD-driven-env-file management; *however*, it doesn't meet the needs for workflows of being able to invoke `ghci` without cursing like a sailor every time we end up in a useless GHCi session because we forgot to throw ourselves into a `cabal v2-exec` subshell in our n-th xterm (or [1]) even though other tooling like `make` or `git` which I'm used to as a developer does the right thing because they honor the common DWIM design principle/idiom for shell-oriented tooling... That being said, I'd be more interested to know the actual problems people are having and trying to address those without throwing the baby out with the bathwater, cause I think many of the problems are of the XY-problem variety here or simply because we did a terrible job at explaining, providing tutorials, or documenting how this feature works, what it is and what it isn't, how it can be used, and what cool new workflows are at our disposal with the upcoming major cabal 3.0 milestone... [1]: ...or even worse, being in the *wrong* subshell while you've already `cd`ed to a different project folder... imagine the amount of cursing you'd exhibit wondering for 5 minutes before you notice you're picking up another project's pkg env...

El 28 mar 2019, a las 3:26 PM, Richard Eisenberg escribió:

[...]

2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones.

I'll second this in one specific context. v2-build has been amazing at work and in general for project-based development, but – and maybe simply because I don't know the right incantations – a step backwards for impromptu coding where I don't want to set up a whole project to start messing with an idea. I've actually fallen back to v1-install for this specific usecase: I have a set of ~15 packages, all installed from local git repos, some of which depend on others, that I *always* want when I'm in GHCi. It's basically my base. I may simply be doing it wrong but I've been unable to use the "global ghc.env file" trick successfully. Tom

To clarify: You mean different installations of same-version GHC? E.g. /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which both happen to be 8.4.4 (so some other version)? - Oleg On 29.3.2019 5.44, Brandon Allbery wrote:

FWIW I've run into this one myself, and use (clones, if necessary, of) v1 sandboxes for it currently.

I've also been both bitten by, and helped by, environment files. The former is somewhat nastier, especially if you have multiple versions of ghc around and a given environment file was generated by a different ghc.

I also have a somewhat weird setup, because of how I ended up cobbling this machine together: the global and user package dbs for my default ghc are more or less "owned" by xmonad development, anything else is in v2, a sandbox, or otherwise a different ghc version. Including nix, also operating as a sandbox (that is, I use an alias to set up nix within specific shells, rather than unconditionally loading its config). Plus that "default ghc" is via wrappers around hvr's ghc repos for Ubuntu. Which means I have lots of different ghcs around, depending on which shell window I'm in. Not that I'm expecting anyone to directly support this mess, but environment files seem to play especially badly with multiple ghc versions with different packages installed.

On Thu, Mar 28, 2019 at 11:33 PM mailto:amindfv@gmail.com> wrote:

> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg escribió: >

[...]

> 2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones.

I'll second this in one specific context. v2-build has been amazing at work and in general for project-based development, but – and maybe simply because I don't know the right incantations – a step backwards for impromptu coding where I don't want to set up a whole project to start messing with an idea.

I've actually fallen back to v1-install for this specific usecase: I have a set of ~15 packages, all installed from local git repos, some of which depend on others, that I *always* want when I'm in GHCi. It's basically my base. I may simply be doing it wrong but I've been unable to use the "global ghc.env file" trick successfully.

Tom _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- brandon s allbery kf8nh allbery.b@gmail.com mailto:allbery.b@gmail.com

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thanks everyone for the lively discussion last week. I think we all understand better now about environment files. GHC reading environment files by default doesn't seem to be a problem as it is just like having more packages installed in the global package DB. This could be convenient. The largest issue with the files is that cabal places relative paths into the environment files which can easily become stale. For example, by deleting the dist-newstyle directory. The absolute paths can also become stale (as Richard discovered). Therefore, it seems the correct course of action is to stop cabal generating the environment files by default. If user's still want to use them then they are easy to enable globally via a configuration setting. This can be achieved by adding the following to your "~/.cabal/config" file: write-ghc-environment-files: always The patch which changes the default behavior is here: https://github.com/haskell/cabal/pull/5985 Cheers, Matt On Fri, Mar 29, 2019 at 4:53 PM Brandon Allbery wrote:

Nix instead of system, but roughly yes.

On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus wrote:

...

To clarify: You mean different installations of same-version GHC? E.g. /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which both happen to be 8.4.4 (so some other version)?

- Oleg

On 29.3.2019 5.44, Brandon Allbery wrote:

...

FWIW I've run into this one myself, and use (clones, if necessary, of) v1 sandboxes for it currently.

I've also been both bitten by, and helped by, environment files. The former is somewhat nastier, especially if you have multiple versions of ghc around and a given environment file was generated by a different ghc.

I also have a somewhat weird setup, because of how I ended up cobbling this machine together: the global and user package dbs for my default ghc are more or less "owned" by xmonad development, anything else is in v2, a sandbox, or otherwise a different ghc version. Including nix, also operating as a sandbox (that is, I use an alias to set up nix within specific shells, rather than unconditionally loading its config). Plus that "default ghc" is via wrappers around hvr's ghc repos for Ubuntu. Which means I have lots of different ghcs around, depending on which shell window I'm in. Not that I'm expecting anyone to directly support this mess, but environment files seem to play especially badly with multiple ghc versions with different packages installed.

On Thu, Mar 28, 2019 at 11:33 PM mailto:amindfv@gmail.com> wrote:

> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg escribió: >

[...]

> 2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones.

I'll second this in one specific context. v2-build has been amazing at work and in general for project-based development, but – and maybe simply because I don't know the right incantations – a step backwards for impromptu coding where I don't want to set up a whole project to start messing with an idea.

I've actually fallen back to v1-install for this specific usecase: I have a set of ~15 packages, all installed from local git repos, some of which depend on others, that I *always* want when I'm in GHCi. It's basically my base. I may simply be doing it wrong but I've been unable to use the "global ghc.env file" trick successfully.

Tom _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- brandon s allbery kf8nh allbery.b@gmail.com mailto:allbery.b@gmail.com

_______________________________________________ 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

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi Richard, For use case 1) we should probably make GHCi be more robust, and make it notice that an environment file has become unusable, say so, and ignore it, rather than refusing to work. It is a bit of an odd way to synchronize build artifacts though. For 2), I like global databases too, and I think that this system is very compatible with it---you can think of the "global" environment as a default project that GHCi uses when there is no other project around. I believe something like that is already being developed. In the mean-time, however, I've just been using one "sand-box" cabal project that has just a cabal file, and no source files---when I want to try stuff out, I just go to that project and fire up `ghci`. It avoids cabal hell as you can easily control the versions of the libraries you need, if you care. It is also cool, in that you can put it on github, and be able to easily recreate the same environment on different machines. And having used that for a while, I've noticed that perhaps I don't really want a global project, as I've evolved a couple of different "sand-boxes" for different topics that I commonly play around with. As for your relevant scenario: couldn't you just add the packages you want to use to your cabal file and ask it to build them for you? Then you'd know what version of the package you are actually experimenting with. I haven't actually run into this issue much, so I can't recall what GHCi says if you try to use a module from a package that is not part of the current context, but it sounds like we may want to improve its message, if the current situation is confusing. On Thu, Mar 28, 2019 at 12:26 PM Richard Eisenberg wrote:

On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel wrote:

That being said, I'd be more interested to know the actual problems people are having

I've run into two problems. I don't expect others to run into these particular problems, as my workflows are likely different than others', but both of these bit me independently.

1. I use two different machines regularly. I keep my files in sync between them using Dropbox. Yet, the Haskell installations between are not identical. Even if the GHC version is the same, it's quite likely that some library, etc., has been installed at a different version on the two machines. (Sometimes, even the GHC is different.) I did some work on a project on machine 1; this produced an environment file. Then, machine 2's window happened to be in the project directory. I wanted to spin up GHCi to check the type of, e.g., traverse. But GHCi wouldn't launch! This is because machine 1's work produced the environment file which invisibly got copied to machine 2 (via Dropbox) and then GHCi tried to respect the environment file, even though I had no interest in interacting with that particular project at the moment. Frustration and confusion ensued.

2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones. This is because, usually, I'm compiling individual Haskell files and not projects. These Haskell files are snippets of code I look at in order to spot a GHC bug and files students email me seeking help on. I therefore like to build up a healthy set of libraries in my global package database so I can just test-drive these files, without worrying about managing dependencies. (It is true that I sometimes run into old-style "cabal hell", but I also accept that this is an unavoidable consequence of using the global package database. By the time this happens, a new GHC has been released anyway, and I use the outdated package database as an excuse to upgrade.)

The actual relevant scenario is this: I open GHCi to load some files from a project, and I want to experiment with them. But I realize that I want to import a few modules from packages not otherwise used in the project (e.g., the 'extra' package) in order to conduct my experiments. But I can't do this, because the env file tells me I can't. Frustration and confusion ensued.

I have a better understanding of all this now -- and the knowledge to disable these features -- but this is how I came to dislike these env files. In both cases, it was because I wanted to interact with Haskell in a way that wasn't fully encapsulated within a project. Perhaps in a "real company", this wouldn't happen, but many Haskellers are not in real companies. :)

Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs