-
Notifications
You must be signed in to change notification settings - Fork 803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uv fails to resolve apache-airflow[all]==2.8.4
where pip succeeds
#3078
Comments
One issue could be pip has a preference on what to backtrack on based on certain heuristics of the users requirements, see:
Whereas my understanding is uv does not apply a preference like this. |
We added the heuristics in #3087 but this still fails for me, for a different reason related to the relationship between extras and the base package. I have some ideas on how to fix it. |
Yeah, I was only speculating that pip's heuristics are part of it. With regards to extras, pip has an optimization that "constrains" extras together with their base requirements: pypa/pip#12095, don't know if that approach will be helpful to you, as no idea how uv handles extras, but for some use cases it was a big performance boost for pip. Also, my understanding is pubgrub-rs strongly implements CDCL to resolve, whereas I would describe pip's approach as "weakly" implementing CDCL, so the path taken through the resolution graph will always be a little different. Though in this case I would think uv's approach would be better, and I do hope to eventually improve pip here and make it's approach to CDCL stronger. |
Unfortunately I still can't get this to avoid going down the |
I won't have time today, but I'll try and make a simpler set of requirements that reproduces this issue. |
Simplifying uv fails with the requirement When I look at the metadata of Spending a lot of time playing around with requirements, I found the issue was a combination of
Edit: Constrained failing requirements even further, and deleted the below comment as I wasn't able to reproduce the results this morning and I don't want people to take it as true if I can't reproduce it. Further I want to investigate why pip skips over |
Okay, I think I've found why pip succeeds here and uv fails, and it's not going to be intuitive. So, currently, pip has a preference on "backtrack causes": https://github.com/pypa/pip/blob/24.3.1/src/pip/_internal/resolution/resolvelib/provider.py#L192 But what are backtrack causes? You might assume that they are the causes that have disjoint requirements, but it turns out resolvelib is sufficiently generic that it doesn't have a concept of disjoint. It just has a concept of that a cause was known to be involved in a failure. So for example, let's say you have A depends on D > 1, B depends on D > 2, and C depends on D < 2, then resolvelib considers A, B, and C to all be causes, even though A's requirements aren't disjoint from either B or C. The effect of this is that pip sort of "wanders" around the possible requirements when there are more than 2 possible causes, resulting in it sometimes being able to find an "unintuitive" solution at the cost of it sometimes being very slow. If I make resolvelib "disjoint aware": pypa/pip@main...notatallshaw:pip:speedy-resolve, then pip ends up getting exactly the same error. As such, I think I'm going to close this issue, as I think uv is doing the right thing here. |
Streps to reproduce
uv pip install --dry-run apache-airflow[all]==2.8.4
Error
Expected
Same as pip, can install fine:
The text was updated successfully, but these errors were encountered: