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