Resolving rejects all wheels for a given version causing otherwise valid wheels to be missed.

[dstufft]

Description

Given these wheels and dependencies:

root -> a == 1
root -> b == 1
b-1-py3-none-any.whl -> a == 2
b-1-py2.py3-none-any.whl -> a == 1

If you run a command like pip install a==1 b==1 then whether or not the resolving succeeds or not depends on whether it "saw" b-1-py3-none-any.whl or b-1-py2.py3-none-any.whl first.

It appears that when resolvelib rejects the first b 1 wheel it finds, it rejects b==1 as a whole, even though the second wheel in that set might resolve fine.

Expected behavior

I expect pip to select the wheel that makes the resolution able to succeed, or at least have consistent behavior regardless of which wheel it sees "first".

In the above scenario, b==1 a==1 and b==1 a==2 should be resolvable on py3.

pip version

25.2

Python version

3.13.3

OS

Linux

How to Reproduce

1. Clone https://github.com/dstufft/pip-wheel-resolver-test
2. Run pip install --dry-run --no-index --find-links=file://$PWD/index a==1 b==1.
3. Run pip install --dry-run --no-index --find-links=file://$PWD/index a==2 b==1.

Output

$ pip install --dry-run --no-index --find-links file://$PWD/index/ a==1 b==1
Looking in links: file:///home/dstufft/projects/pip-wheel-resolver-test/index/
Processing ./index/a-1-py3-none-any.whl
Processing ./index/b-1-py2.py3-none-any.whl
Would install a-1 b-1

$ pip install --dry-run --no-index --find-links file://$PWD/index/ a==2 b==1
Looking in links: file:///home/dstufft/projects/pip-wheel-resolver-test/index/
Processing ./index/a-2-py3-none-any.whl
Processing ./index/b-1-py2.py3-none-any.whl
INFO: pip is looking at multiple versions of b to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install a==2 and b==1 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested a==2
    b 1 depends on a==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 to attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[notatallshaw]

Thanks for the report.

You're calling out resolvelib but I don't think you mean https://github.com/sarugaku/resolvelib but rather pip's resolution process?

As I understand it you're saying if two candidates of the same version have different resolution metadata, pip will not iterate through the candidates to find a version that has metadata that can resolve the resolution?

If that's the question, the answer is yes, that is by design:

1. Pip's collector chooses 1 candidate per project per version
2. Pip's resolver resolves project per version, not candidates

If this is an issue for you I would recommend the same as uv recommends, includes your full requirement metadata in each candidate and use markers to differentiate what they are for, e.g.

a==1; python_version < '3',
a==2; python_version >= '3',

Let me know if I've misunderstood something about your report.

[dstufft]

You're calling out resolvelib but I don't think you mean https://github.com/sarugaku/resolvelib but rather pip's resolution process?

I'm not super familiar with where the responsibility between resolvelib and pip's wrappers around resolvelib lie, I was remarking where it appeared the cause to reject everything under that version happened.

As I understand it you're saying if two candidates of the same version have different resolution metadata, pip will not iterate through the candidates to find a version that has metadata that can resolve the resolution?

If that's the question, the answer is yes, that is by design:

1. Pip's collector chooses 1 candidate per project per version
2. Pip's resolver resolves project per version, not candidates

The answer is yes, but it's not clear that it's by design?

Certainly it didn't used to be by design when I was still active, but it's been a good bit since I was, so I did double check with @pradyunsg before opening this issue, and he thought it was a bug.

Python standards have been that metadata is per artifact, not per version, and on thread on discuss.python.org about metadata consistency both @pfmoore and @pradyunsg are talking about pip as if it doesn't make the same simplifying assumption that uv does (and in fact @pradyunsg is in that thread saying that he thinks that we cant' assume that wheels have the same metadata).

[pradyunsg]

I think the change to make here is to have the collector consistently order these wheels, so that we prefer one with fewer tags, so that pip's behaviour here is consistent across runs.

[pradyunsg]

To be clear, I don't think pip should be trying multiple options for the same package+version combo. We'd done thag in the initial iteration and ended up with the "select one and move on" design instead.

[notatallshaw]

Pip doesn't make the same simplifying assumption as uv because uv does a "universal resolution" for all environments, i.e. it's output should be good for any environment you've installed on.

There can't be a universal resolution on your candidates here because from a universal requirements perspective you've effectively expressed:

• When Python is either v2 or v3: a==1
• When Python is v3: a==2

So the universality of your requirements are logically impossible for Python v3.

Pip side steps this problem by only resolving for your current environment, and the way it does that is it pick the "best" candidate for each project per version and resolves against that. This is the design of pip here, as best as I can tell, is working as intended here in your example.

Changing the design to mix candidate selection logic and resolution logic is likely to make pip's resolver logic way more complicated, and likely preclude pip from using any sort of modern solver algorithm, which I have been trying to, very slowly, lay the ground work for by finding and fixing logical inconsistencies in pip's selection and requirement logic. So unless there is some clear insight on this I am missing I am likely to be strongly -1 on changing.

[notatallshaw]

I think the change to make here is to have the collector consistently order these wheels, so that we prefer one with fewer tags, so that pip's behaviour here is consistent across runs.

Oh yeah, that's fine! (I posted the above before seeing your posts sorry)

This problem though will manifest the other way around, if a candidate could solve the resolution but it has more tags then pip's resolver won't see it and it will return resolution impossible. I think in @dstufft two examples, one of them will always return a resolution impossible.

[dstufft]

The fundamental questions are whether having two wheels with the same version with different dependencies is valid or not, and if they are, whether pip wants to support those valid wheels or not.

As far as the specs are concerned it's valid as far as I know, there's nothing in the specs that require that two wheels with the same version have the same dependencies.

In my above example b 1 depends on different versions of a depending on which wheel file is selected.Order only really matters in that it controls whether things work or not given a specific command. Ultimately in my above example, both pip install b==1 a==1 AND pip install b==1 a==2 is resolvable, but currently pip will only work if the a constraint on the CLI happens to match the a constraint in the first wheel it checks.

Pip can of course decide it doesn't support otherwise valid sets of wheels. Though I suspect if the variant proposal ends up ultimately being approved at some point, this issue will end up being forced to be solved somehow because it will become more common for there to be different wheels with different dependencies that are equally valid for the current environment with mutually exclusive overlapping constraints.

[notatallshaw]

The fundamental questions are whether having two wheels with the same version with different dependencies is valid or not, and if they are, whether pip wants to support those valid wheels or not.

The wheels are valid, they are just logically inconsistent with each other from a resolution perspective.

As far as the specs are concerned it's valid as far as I know, there's nothing in the specs that require that two wheels with the same version have the same dependencies.

The spec never considers or makes any statements on resolution, it says nothing about how an installer should behave for more than one requirement, so statements like b==1 a==2 are not defined anywhere in the spec.

In my above example b 1 depends on different versions of a depending on which wheel file is selected.Order only really matters in that it controls whether things work or not given a specific command. Ultimately in my above example, both pip install b==1 a==1 AND pip install b==1 a==2 is resolvable, but currently pip will only work if the a constraint on the CLI happens to match the a constraint in the first wheel it checks.

In your example, in the same environment, pip can only support b==1 a==1 or b==1 a==2 not both, coming up with a resolver that supports both will likely lead to common pathological resolution issues.

Though I suspect if the variant proposal ends up ultimately being approved at some point, this issue will end up being forced to be solved somehow because it will become more common for there to be different wheels with different dependencies that are equally valid for the current environment with mutually exclusive overlapping constraints.

No, the variant proposal designed to be a plugin to pip's collector, not to it's resolver, so the variant plugin will select a new best candidate, pip's resolver will continue to only resolve against that one selected candidate per project per version.

[dstufft]

No, the variant proposal designed to be a plugin to pip's collector, not to it's resolver, so the variant plugin will select a new best candidate, pip's resolver will continue to only resolve against that one selected candidate per project per version.

This is getting a little off track here so I'm happy to go away for right now :) But I do want to call this out that this is technically correct, but the implications of that means that the "problem" in this thread will effectively occur (and in fact, it will occur with the metadata being equal between two wheels).

A concrete example from the variant proposal, is that something that depends on pytorch may be able to be built against many versions of pytorch, but once they're built against a specific version of pytorch the runtime dependency on pytorch has to be ABI compatible with the build time dependency.

So that means you can have a library foo, that has dependency metadata like this:

pytorch==2.8.0; "abi::torch::2.8.0" in variant_properties
pytorch==2.7.1; "abi::torch::2.7.1" in variant_properties
pytorch==2.7.0; "abi::torch::2.7.0" in variant_properties

You can't know which of those 3 variants you want to select, until you've already selected a version for pytorch, and you'd get the "null" variant (e.g. no specific variant), which is probably against the latest version of pytorch. However, all those variants would be compatible with the current system, and if someone did specify a specific version of pytorch, you'd end up in the exact situation as in this issue. Whether or not it worked or not would depend on which of the 3 compatible variant wheels pip happened to look at first.

I originally expected this to be a non-problem for pip, because it used to be that pip treated each artifact as it's own thing and handled inconsistent metadata between different artifacts fine, but when I went to test it, I ended up discovering that pip does not handle this anymore.

See wheelnext/pep_xxx_wheel_variants#87 for more information.

[notatallshaw]

The following:

pytorch==2.8.0; "abi::torch::2.8.0" in variant_properties
pytorch==2.7.1; "abi::torch::2.7.1" in variant_properties
pytorch==2.7.0; "abi::torch::2.7.0" in variant_properties

is okay as long as they are expressed in every variant, as I suggested in the DPO thread: https://discuss.python.org/t/wheelnext-wheel-variants-an-update-and-a-request-for-feedback/102383/194

If this can't be done and this problem is real in pip (I'm still not understating why you can't express all requirements using environment markers in each candidate/variant) then I will be -1 on the variant PEP, and if it passes -1 on implementing it in pip if it touches any of the resolver code, it will make Python package resolution libraries go deep into mathematically unexplored solver territory (which they probably already are pushed a little in to, due to the nuances on the version specifier spec, and is the cause of many of the problems in the Python package resolver space).

[notatallshaw]

Wait, I reread what you said, are you saying variant_properties depends on the current active state of the resolution? If so I am a GIANT -1 on that, how do you expect backtracking to work?

[notatallshaw]

:) But I do want to call this out that this is technically correct, but the implications of that means that the "problem" in this thread will effectively occur (and in fact, it will occur with the metadata being equal between two wheels).

No, this isn't technically correct, this is the core principle that makes variants acceptable as part of resolution, variant plugins should only have information to the system environment, which should be static for the state of the resolution, and the information the collector has, which should be static per project per version.

Variant plugins should not have any information from the resolver, otherwise there is no way to apply any kind of logical inference from resolution states in the solver, for example if a=1 b=1 is unsatisfiable at any point, then it should remain unsatisfiable, no matter what changes about the rest of the resolver state. If that does not hold then you can not implement any kind of modern algorithmic solver speed up, which pip is desperately in need of for complex resolution.

[dstufft]

variant_properties doesn't depend on the current active state of resolution no.

variant_properties is effectively a set of strings that is an intersection of the set of strings from the wheel artifact itself and the output of the plugin (that runs prior to resolution) that indicates what variants are compatible with the current system.

So given you have a variant that indicates what ABI of pytorch you're running against, you might end up with 3 variant wheels.

foo-1.0-Variant1
  - Valid for `"abi::torch::2.8.0"`
foo-1.0-Variant2
  - Valid for `"abi::torch::2.7.1"`
foo-1.0-Variant3
  - Valid for `"abi::torch::2.7.0"`

All 3 of these wheels have the following metadata:

Requires-Dist: pytorch==2.8.0; "abi::torch::2.8.0" in variant_properties
Requires-Dist: pytorch==2.7.1; "abi::torch::2.7.1" in variant_properties
Requires-Dist: pytorch==2.7.0; "abi::torch::2.7.0" in variant_properties

If someone runs pip install foo, then the following would (in the hypothetical that variants land) happen:

1. During collection, pip would invoke the pytorch abi provider, which would say that this system is compatible with {"abi::torch::2.8.0", "abi::torch::2.7.1", "abi::torch::2.7.0"}.
2. Pip would see those 3 variants, see that they're all compatible with the current system and collect all 3 of them.
3. Resolve, picking whichever one of them it saw first (let's say it's Variant1, which depends on pytorch==2.8.0 through the environment markers).
4. Install foo 1.0 (Variant1) and pytorch 2.8.0.

However, the fact it selected Variant1 was just due to that one being "first", all 3 variants were equally valid.

So what if instead the user ran pip install foo pytorch==2.7.*? The following would happen:

1. During collection, pip would invoke the pytorch abi provider, which would say that this system is compatible with {"abi::torch::2.8.0", "abi::torch::2.7.1", "abi::torch::2.7.0"}.
2. Pip would see those 3 variants, see that they're all compatible with the current system and collect all 3 of them.
3. Resolve, picking whichever one of them it saw first (let's say it's Variant1, which depends on pytorch==2.8.0 through the environment markers).
4. Throw a resolution error.

In the latter case, if pip didn't lump all 3 variant wheels together and reject all 3 because one of them failed, then (4) would be successful, because pip would reject Variant1, then move onto Variant2, and the marker evaluation would say that it depended on pytorch==2.7.1.

It has nothing to do with variants getting information into or out of the resolver, and it's not even really specific to variants at all. The generalized problem is what do you do when there are multiple wheels that can satisfy foo==1.0 and the effect of selecting one of those wheels over the other changes the ultimate set of dependencies to be installed.

The easiest (maybe only?) way to have this happen today is to have two wheels, that are valid for the current platform+python version, with different METADATA files that have different Requires-Dist entries, but I think you can run into it mixing py3 and cpXY wheels and environment markers. In any case, this case will be more likely with variants, because in most cases projects do not have overlapping wheels like that currently.

Another way of thinking about it is that currently pip assumes that the effect on the dependency graph of selecting foo-1.0 will be the same regardless of which wheel you select, so foo-1.0 is effectively the "node" for the dependency graph. Solvers like uv already know this isn't the case when they're attempting a universal solve, because selecting a windows wheel might pull in different dependencies than selecting a linux wheel, so they fork the resolution for those cases (they're using environment markers instead of wheels themselves, but that's immaterial here).