Incorrect failure message when multiple specifiers mention the same package, one of them pointing to a wrong version

[Arpafaucon]

In the following case, the new dependency resolver exits with an incorrect error message. It does not help the user debugging the situation.

I have multiple requirements.txt files that I want to install in a single shot. To do so I run pip install -r <req_file> -r <other_req_file> .... With the new resolver, some impossible configurations are detected but with an unhelpful (incorrect?) error message.

I'll take the specific example of pdbpp:

• v0.10.2 exists
• v0.10.1 DOES NOT EXIST

req_a.txt

# that's I'll call the wrong file
# requesting an invalid version
pdbpp==0.10.1

req_b.txt

# the "good" file
pdbpp

---

run A: only the wrong version, old resolver

$ pip install -r req_a.txt 
ERROR: Could not find a version that satisfies the requirement pdbpp==0.10.1 (from -r req_a.txt (line 1)) (from versions: 0.6, 0.7, 0.7.1, 0.7.2, 0.8.dev0, 0.8.dev1, 0.8, 0.8.1, 0.8.2, 0.8.3, 0.9, 0.9.1, 0.9.2, 0.9.3, 0.9.5, 0.9.6, 0.9.7, 0.9.8, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15, 0.10.0, 0.10.2)
ERROR: No matching distribution found for pdbpp==0.10.1 (from -r req_a.txt (line 1))

The error message is appropriate. The user is clearly informed that its version spec cannot be resolved

run B: only the wrong file, new resolver

$ pip install -r  req_a.txt --use-feature=2020-resolver
ERROR: Could not find a version that satisfies the requirement pdbpp==0.10.1
ERROR: No matching distribution found for pdbpp==0.10.1

The message is less helpful, but still valid.

run C: both files, wrong file before, new resolver:

$ pip install -r  req_a.txt -r req_b.txt --use-feature=2020-resolver
ERROR: Could not find a version that satisfies the requirement pdbpp==0.10.1
ERROR: No matching distribution found for pdbpp==0.10.1

Same message, still valid

run D: both files, good file before, new resolver

$ pip install -r  req_b.txt -r req_a.txt --use-feature=2020-resolver
ERROR: Cannot install pdbpp and pdbpp==0.10.1 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested pdbpp
    The user requested pdbpp==0.10.1

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

This message is unhelpful: it suggests there is a conflict between both files, though one of the requirements is obviously valid with any version

Additional information

System info:

• ubuntu 20.04
• python 3.6.9
• pip 20.2.3

Other remarks

• This can be reproduced in a pristine virtual env.
• This issue can be reproduced with the in-development version of pip (pip 20.3.dev0)

[pradyunsg]

@pfmoore Maybe you have more context on why the error message generation logic here is presenting the wrong information?

[uranusjr]

I think the solution to #8495 would also resolve this.

[pfmoore]

@uranusjr is correct, #8495 is the resolution here.

The difference between "run A" and "run B" is due to the fact that the new resolver doesn't check versions the same way as the old one, so we don't have easy access to the information about which versions we ignored. Agreed the new report can be less helpful, but I've also seen cases where the list of ignored versions is so long that it's more distraction than help, so I think that the difference there is probably acceptable.

I believe the difference between runs C and D is because the new resolver collects a starting list of candidates from the first requirement it encounters. It then merges subsequent requirements. If the first list is empty, we can say "could not find a version" because we know there's nothing valid, but if a merge causes the list to become empty later, we don't have enough context on why (it could be that nothing satisfies the constraint, but it could equally be a conflict like A>1.0 and A<1.0) so all we can say is "conflicting requirements".

The hard issue here is that while a human can look at the global picture, especially in the simpler cases that tend to come up in reproducing bugs, the code has a very "local" view of what happened, and you need the global picture to produce a good error message. I don't know what a good answer is here - my view is that we should be trying to give the user a better picture of what the resolver was doing when the problem occurred, but the internal logic of the resolver is complex, and explaining enough of "what went on" to make the problem clear is tricky (and it requires users to be willing to invest time in understanding at least part of the resolution algorithm). The initial feedback from the UX studies suggested that users weren't comfortable with error messages that exposed that sort of detail - but we haven't yet worked out how we can write the sort of errors that give the "high level" explanation.

[uranusjr]

Combining this into #8495