Disable .ghc-environment file generation by default

[mpickering]

See https://mail.haskell.org/pipermail/ghc-devs/2019-March/017351.html for discussion about this default.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

[hvr]

While I still consider most of the arguments brought forward for changing the default to be weak and in some cases even irrational, and I therefore remain unconvinced by those, I'm willing to reconsider the default setting for the upcoming 3.0 release; it's not like like we can't change the default back once we've worked out the few remaining kinks.

[23Skidoo]

LGTM modulo comments.

[mpickering]

@23Skidoo I made your suggested changes.

[vaibhavsagar]

Thank you for doing this @mpickering!

[hvr]

Just as a reminder, we need to make a couple of follow-up changes to prevent bad user-experience as a result of this change of defaults, as ironically changing the default this way will guarantee a couple of regression for cabal users if caught off guard.

[gbaz]

Let me expand on that -- in an irc discussion with someone who had been quite frustrated with env files, it turns out the problem was precisely that we'd limited their auto generation to 8.4.4 and after. Hence, they had files for 8.4.3, etc projects that were out of date, and which weren't getting auto-regenerated (due to changing defaults), and this was what made the env files fail for them.

So, in particular, we need to handle the case where someone updates cabal, then env files stop being generated, and then workflows break without their realizing it.

What this suggests to me is we need some behavior when env files already exist that A) detects them and B) either warns, offers to delete, or says "if they already exist, then update them" -- i.e. the default is not "don't create or update" but rather "don't create, but do update".

[hsenag]

"don't create but do update" sounds good for the long-term behaviour as it's then opt-in - particularly if it can detect the cabal-generated files and only update those and not one created directly by a user.

In common with many others I'm against the current behaviour: it's both a layering violation (a high-level tool cabal modifying the behaviour of a low-level tool ghci) and a silent side-effect.

[kcsongor]

@gbaz I like your proposal about issuing a warning when the environment file is not being generated, as I've run into a similar situation myself.
However, I think it might be better to always show the notice, even if old env files don't exist. My travis CI broke after the cabal-head package was updated, and my doctests (which relied on the env files) suddenly stopped working. Since travis runs a clean build every time, the warning would not have been shown. If I got a warning about the env file not being generated, it would have been a little easier to get to the bottom of the problem.

Would always issuing a warning cause issues elsewhere?

[phadej]

Showing the notice that “environment files not generated” would be acceptable only for verbose output, but then it would be good to be implicit; especially if “don’t create, but update” variant is added.

…

On 6 Apr 2019, at 13.48, Csongor Kiss ***@***.***> wrote: @gbaz I like your proposal about issuing a warning when the environment file is not being generated, as I've run into a similar situation myself. However, I think it might be better to always show the notice, even if old env files don't exist. My travis CI broke after the cabal-head package was updated, and my doctests (which relied on the env files) suddenly stopped working. Since travis runs a clean build every time, the warning would not have been shown. If I got a warning about the env file not being generated, it would have been a little easier to get to the bottom of the problem. Would always issuing a warning cause issues elsewhere? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[phadej]

I meant explicit as in always be present, whatever the setting is

…

On 6 Apr 2019, at 14.38, Oleg Grenrus ***@***.***> wrote: Showing the notice that “environment files not generated” would be acceptable only for verbose output, but then it would be good to be implicit; especially if “don’t create, but update” variant is added. > On 6 Apr 2019, at 13.48, Csongor Kiss ***@***.***> wrote: > > @gbaz I like your proposal about issuing a warning when the environment file is not being generated, as I've run into a similar situation myself. > However, I think it might be better to always show the notice, even if old env files don't exist. My travis CI broke after the cabal-head package was updated, and my doctests (which relied on the env files) suddenly stopped working. Since travis runs a clean build every time, the warning would not have been shown. If I got a warning about the env file not being generated, it would have been a little easier to get to the bottom of the problem. > > Would always issuing a warning cause issues elsewhere? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread.

[gbaz]

One other suggestion I would like to make -- I think we should have the "disable" setting in general control if the files are created in the project directory. However, we should probably either also unconditionally (or at least when files are not created in the project directory) create an appropriately named file (perhaps without a dot) in the dist-newstyle (or dist, i don't remember if we're renaming dist-newstyle to dist or not) directory, so that tools which start to make use of these files explicitly can know where to find one regardless of other settings.

Since part of the whole issue has been to make things as seamless as possible for various tooling, I think keeping that design consideration in mind going forward as well could be important.

[phadej]

I merged this. It's already an improvement, and following refinements can be done separately.

[23Skidoo]

Also cherry-picked into 2.4. On reflection, I decided to revert the 2.4 cherry-pick since changing behaviour so drastically in minor releases is surprising and additional improvements in env file generation mentioned above haven't been implemented yet.