Add config flag to control generation of .ghc.environment files

[hvr]

Some people are excited about .ghc.environment files, while others are mildly annoyed. I think there's probable cause to make this configurable on cabal's end.

To this end, I suggest (modulo bikeshed) to implement a flag, e.g. --pkg-environment-scope=LEVEL, where LEVEL can be one of

1. all (default & current behaviour, generate ghc env files with all transitive dependencies of project's (non-qualified) goals)
2. build-target (e.g. :pkg:Cabal or lib:Cabal or Cabal:test:parser-tests): generate ghc env files containing only the stated goal's /direct/ dependencies)
3. - (or none or off or disable?): disable generation of any ghc env files

This flag would also be persistable via cabal.project.(local).

Note: Item 2. is not the short-term goal of this feature request! I've included the 2. item mostly to motivate why it makes sense to design this to be a flag that's more than merely a boolean --{disable,enable}-package-environment-files flag.

Btw, a dual feature-request (allowing to opt-out from interpreting .ghc.environment files from GHC's side) has been filed at GHC #13753 -- however, that one will be too late for GHC 8.0.2 users.

Current status:

• Starting with GHC 8.4.3, ghc is more verbose when picking up pkg envs (see http://git.haskell.org/ghc.git/commit/00049e2dce93b1e468c3fde3287371eb988aafdc)
• Starting with GHC 8.4.4, ghc supports the special - environment which inhibits the default lookup logic (see http://git.haskell.org/ghc.git/commit/8f3c149d94814e4f278b08c562f06fc257eb3c43)

/cc @RyanGlScott

[ezyang]

So, I've recently been working in the Python/Anaconda world, where they have scripts like source activate myenv which kick you into an alternate shell where when you call python, you get the environment (interpreter, packages, etc) correspond to the particular environment you are working on. Letting this setting be done on a per shell basis seems better to me than setting it to file path location? (Yes, I know this is totally asking GHC environments to be redone, but it seems to me like it would solve the root cause of the problem you're describing above, as well as other problems.)

[hvr]

Tbh, I have been working with Python's virtualenvs for quite some time, and they were somewhat unsatisfying to me. I prefer the git-style approach which has been copied by many tools which are $CWD sensitive. I don't want to have to remember and having to explicitly perform redundant keystrokes to enter an environment other than simply cding into a project, and have my tool follow the DWIM principle. If we require to explicitly enter environments, we still have cabal exec or cabal repl; but that's a different paradigm (which has its uses) from what GHC environment files provide. Since GHC environments started working in cabal head, I've reduced my use of cabal new-repl to quite a lot less.

This ticket is primarily to help those who don't subscribe to that paradigm, and want to opt-out.

[alanz]

I just spent a significant chunk of time trying to get a project to build and run tests, using stack. I build the project using both cabal master and stack, to check that it works for both.

Having deleted the dist* directories and built with stack, the tests failed, complaining about a missing package db in ./dist-newstyle.

After re-installing everything haskell related, I eventually tracked it down to this file being silently generated, and then being picked up by other tools.

At this stage I would prefer to opt in for this generation, or at least get something in the output to say that the file has been generated, so that I can know that a potential landmine has been planted.

This is bound to trip up others as well, as the existence and use of this file is not well documented.

[ezyang]

I agree that this state of affairs is not great. @hvr, can we perhaps change this setting to be opt-in?

[23Skidoo]

Can we get stack to turn off parsing of .ghc.environment files with -hide-all-packages?

/cc @mgsloan

[cocreature]

fwiw nix also breaks in some cases due to .ghc.environment.* files so I don’t think that a workaround in stack is the right solution here.

[gbaz]

As per https://www.reddit.com/r/haskell/comments/8iyvoo/psa_for_cabal_22_new_users_regarding/ I think that the weight of opinion is that these files should not be auto-generated, but only by opt-in.

If we add this flag as a global flag that can be in ~/.cabal/config and off by default then that would help. Then if people wanted such a config, they could run cabal new-configure --package-environment-scope=ALL.

I think that would improve the situation for a whole bunch of workflows...