The resolver needs to be able to cope with currently-broken installations

[pfmoore]

Something that occurred to me when looking at pypa/pip#5196 was that when the new resolver is added to pip, we will likely have a number of cases where the user's current installation might be inconsistent - not with the requirements being installed, but within the existing requirements. It's going to be important that the resolver handles this sort of situation gracefully.

I don't have any specific suggestions here at the moment, but I wanted to record the point while it was fresh in my mind, so it doesn't get forgotten.

[pradyunsg]

This was actually one of the first things I thought of when I was starting and it actually falls under the umbrella of "the resolver would always make the user end up with a consistent dependency graph".

If the current installed state is broken, it would be possible to have the resolver explore versions other than the ones currently installed for trying to unbreak the environment. From a resolution point of view, it's just a matter of providing the resolver with all the possible versions of a package, with a preference for the currently installed one. The resolver would then choose a consistent set of packages, if it can, like it's supposed to.

This does mean that if you want to just install a package in a broken environment, without fixing that environment, you would no longer be able to do so -- unless we have some way to ignore everything else in the environment. Staying functional in that environment is definitely possible and maybe I'll look into enabling that if it makes sense for us -- I don't think it does.

The more interesting/difficult part of the puzzle might be the actual UX here -- something I think we should get into when we have a PR to discuss it on. :)

[pfmoore]

I don't personally have a use case for it, but I imagine some people will need to be able to "just install X" without being blocked by problems with packages not in the dependency graph of X.

A more complex case. X depends on Y and Z, and Y 1.0 depends on Z>1.0. Y 1.0 and Z 1.0 are already installed. The installation is broken, but it nevertheless does satisfy the declared requirements of X (that Y and Z are present). Should installing X trigger reinstalls of either Y or Z? If so, why? I suspect that the "intuitive" answer is that by default, pip shouldn't try to "fix" existing installs unless asked to, or it's not possible to satisfy the top-level dependencies of the specified requirements. In that case, it would make sense to have a --fix-installed flag to do a full pass.

Agreed that a lot of this is UX discussion, which can be deferred, but I think that it's quite possible that the resolver having an "assume that installed packages are valid" mode will be important to at least some people.