+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: - nix-shell - virtualenv - rbenv - sbt - jenv 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. Plus, as functional programmers this is just the sort of idiom we use all the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`. On the negative side: I've helped ~6 people at my company alone debug issues due to environment files. Two of those were novice users (the people whom this feature is supposed to help). In my experience it breaks people's assumptions about what sort of things influence compiler invocations. People don't expect a stateful dependency from a previous run of a build tool to a later run of a lower-level compiler. Moreover, the failures can be mystifying, and I was only able to help because I already knew "get rid of any environment files" as a solution to "weird dependency issues". *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`.
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.
M
On Thu, Mar 28, 2019 at 5:02 PM Bardur Arantsson
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