install --lib can create inconsistent environments when dependencies are involved

[fgaz]

Describe the bug

install --lib can create inconsistent environments when packages are installed one by one (ie. when an environment is modified). This was fixed for the case of explicitly installed packages, but not for dependencies.

To Reproduce
Steps to reproduce the behavior:

foo depends on bar. Constraints simulate the evolution of the index.

$ cabal install --lib foo --constraint=bar==1

Now suppose a function f from foo returns/takes a type from bar. I install bar so I can interact with f:

$ cabal install --lib bar --constraint=bar==2

Poof, inconsistent environment. The two instances of bar don't match.
The second command succeeds because bar is not explicitly in the environment.

Expected behavior

One of

• failure when inconsistencies are detected
• failure when trying to update an environment (RFC: don't allow cabal install --lib to update environment files #8483)
• apply constraints from transitive dependencies from the exisitng environment, not only from top-level stuff
• rebuild the plan from scratch if necessary, like cabal-env does
  • Separate cabal install --lib into own command (cabal env) #6481 (comment)
  • cabal new-install, environment files, and unsolvable constraints #5559 (comment)

System information

• NixOS 23.11
• GHC 9.4.8
• cabal 12223d7

Additional context
Add any other context about the problem here.

• RFC: don't allow cabal install --lib to update environment files #8483
• RFC: don't allow cabal install --lib to update environment files #8483 (comment)
• cabal new-install, environment files, and unsolvable constraints #5559

[ulysses4ever]

Poof, inconsistent environment.

Could you explain what is wrong with the resulting environment, explicitly? It’s not clear to me. There are two problems. First, we don’t have a formal definition of an inconsistent environment, and it’s good to explain what exactly is meant here. Second, you don’t explain how the running example is “inconsistent” given the definition that you will have when address the first point.

[gbaz]

Could you explain what is wrong with the resulting environment, explicitly?

Suppose I install foo depending on one version of containers and foo has a function that outputs a Set. But I can't work with that set because containers isn't yet installed itself (as an entry in the env file). Ok, so I install containers but now the solver gives me a different version. Now, the installed containers can't work with the result of that function in foo.

I noticed this problem here btw and suggested one approach: #8607 (comment)

But I'm wondering now if recording the hashes of all the transitive deps in the env file might be the more appropriate thing to do?