Ah, I have binary-0.8.6.0-222faad0b96ef53407dce965dc89112e160faf581189155f9f85c78ac94c8925 in '.ghc/x86_64-linux-8.4.4/environments/default`, how to remove it?

I tried with a clean environment, installing lens (with ghc-8.4.4) there; why

package-id unix-2.7.2.2-953b32e4e99583a69a7d744cd659fdafb48201a0167b29e542dbaa31b66f98df
package-id binary-0.8.6.0-222faad0b96ef53407dce965dc89112e160faf581189155f9f85c78ac94c8925
package-id text-1.2.3.1-30c2d2c5658da41475e0d6ff2b03e5f0a3d2125cb0e7e1cd1cfe1d5d1d7312f6
package-id lens-4.17-82c556af7bbffe41e3c93fa447e77117b4711e6322f3d7dd7f2feb4e0de29dab

pops into that environment? It doesn't make sense to me. If I try later to install something in that environment, it will fail as above.

Isn't this basically #5559 ?

This turns out to be a little different:

[FL973] ~ % rm -rf ~/.ghc/x86_64-linux-8.4.4/environments
[FL973] ~ % cabal new-install --lib lens
Resolving dependencies...
Up to date
[FL973] ~ % cabal new-install --lib lens
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: binary-0.8.6.0 (user goal)
[__1] next goal: ghc (user goal)
[__1] rejecting: ghc-8.6.1 (constraint from user target requires ==8.4.4)
[__1] rejecting: ghc-8.4.4/installed-8.4... (conflict: binary==0.8.6.0, ghc =>
binary==0.8.5.1/installed-0.8...)
[__1] rejecting: ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1 (constraint from
user target requires ==8.4.4)
[__1] fail (backjumping, conflict set: binary, ghc)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: binary, ghc

I'd expect new-install --lib foo to be idempotent.

The failure of cabal v2-install --lib foo to be idempotent is a symptom of #5559 too... which is why #5559 is high-prio :-)

cc @typedrat

Just ran into on IRC someone with this as well -- in that case they ran new-install on a lib, just to test building it, and later tried to new-install the ghcid binary, and got a weird constraint error. I think at a minimum, new-installing a binary should just not make use of any ambient env files, since the user doesn't care about putting that into a consistent store, just getting the working executable.

Further, I think that we should have, absent any fancy heuristics, at least just a good check and warning if there's env-file induced constraints causing a failure, so it can direct users to the source of the problem immediately.

@gbaz do we have a repro for env files affecting v2-install of executables? So far I was only aware that (by design) an in-scope cabal.project file will affect v2-install, but not that environments would be picked up.

So is not this a manifestation of #5559 at the end?, maybe we should bring them together