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