-
Notifications
You must be signed in to change notification settings - Fork 732
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
Support Python version upper bound in uv pip compile --universal
#4959
Comments
Hmm, #4732 might be related here. In particular, the marker expressions are overlapping, so I think the universal resolver is probably not forking in this case. And indeed, trying it out locally, I can see that no forks occur. But, because there are no forks, it seems to me like
OK, so looking at the metadata for
Converting that to
And running
But indeed, just
Ah okay, now I think I get it. This is the key piece I was missing:
Right, so even though I do think that #4732 should be able to fix this. Namely, if we modify the universal resolver to fork in this case, then I think it should be possible to do the right thing here. With that said, I'm not sure we've fully tackled the interaction points between pre-releases and universal resolution yet. |
In addition to #4732 and the great explanation by @BurntSushi, i think we also need #4579 to solve. |
## Summary Similar to #5232, we should also track prerelease strategies per-fork, instead of globally per package. The common functionality for tracking locals and prerelease versions across forks is extracted into the `ForkMap` type. Resolves #4579. This doesn't quite solve #4959, as that issue relies on overlapping markers.
I believe this now works as expected:
|
Using uv 0.2.23, the following fails to resolve:
The issue here is that
persistent==6.0
depends on the following:The 1st one is fine and resolves to
cffi==1.16.0
without--universal
, however the 2nd one is a dependency on a prerelease-only package version range for a prerelease-only Python version, and as such fails unless we enable all prerelease versions.Being able to specify an upper bound (e.g.
--max-python-version 3.12
, though an exclusive bound might be better) would allow for a successful resolution.I was also wondering whether this issue is a bug since this concerns a prerelease Python version that should probably be ignored, but:
The text was updated successfully, but these errors were encountered: