ignore an externally set $GHC_ENVIRONMENT

[fgaz]

Currently a bogus $GHC_ENVIRONMENT can make cabal fail. Cabal itself could trigger this issue if it's called inside a cabal exec (though this is probably a terrible idea in the first place). Local and default environments instead do not cause any interference.

Should we always pass -package-env=- to ghc, or set $GHC_ENVIRONMENT to -?

I think yes:

• Cabal manages the set of packages it passes to ghc on its own, so why should it be affected by external environments?
• I don't see any use for passing an environment to cabal
• it can cause inscrutable errors

on the other hand:

• resetting a variable that may heve been explicitly set by the user does not sound good

[Mikolaj]

I'm for ignoring the env var, if possible.

[phadej]

Hmm, in https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments

Additionally, unless -hide-all-packages is specified ghc will also look for the package environment in the following locations:

File .ghc.environment.arch-os-version if it exists in the current directory or any parent directory (but not the user’s home directory). File $XDG_DATA_HOME/ghc/arch-os-version/environments/default if it exists.

But the $GHC_ENVIRONMENT is not ignored.

Note that -package-env=- doesn't work on all GHCs which support -package-env flag.

I'd say it's simpler for cabal to always reset environment clearing GHC_ENVIRONMENT, rather then trying to undo its effects with flags.

[fgaz]

Given the positive response I'm going to turn this ticket from "discussion" to "enhancement"+"pr welcome".

Some stuff to pay attention to when implementing:

• should it be reset in cabal-install or Cabal? (probably the latter)
• if we want to keep tools such as doctest working, the variable should only be reset for ghc calls, not globally or for other executables

[andreabedini]

Why not treating GHC_ENVIRONMENT like GHC_PACKAGE_PATH and die.

[sternenseemann]

Why not treating GHC_ENVIRONMENT like GHC_PACKAGE_PATH and die.

This would break quite a few test suites that rely on cabal exec setting GHC_ENVIRONMENT so that a test suite can invoke ghc/ghci and have build depends available. One such example is doctest.

Cabal 3.12 caused the check for GHC_PACKAGE_PATH to be executed when running test suites, so it seems you now would need to use GHC_ENVIRONMENT. (An alternative could be to use --test-wrapper to sidestep this check, but this seems like an unsatifactory solution.)

Not saying GHC_ENVIRONMENt being disallowed is wrong per se, but I don't see an alternative for this use case at the moment. The existing real world usage of this is significant (i.e. anything using doctest would also be affected).

[mouse07410]

This is a years-old discussion, and frankly I don't see it's purpose.

If GHC_ENVIRONMENT that user set has bad value - then Cabal would fail, which is to be expected. If that value makes sense - fine.

Where's the nail that this discussion/hammer is trying to hit? What's the actual problem?