-
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
Narrow requires-python
in forks
#4669
Comments
My guess is that |
See also #4668 for another variant of this issue. |
I can give this a try... Important correctness issue. |
This is pretty tricky because we build the |
I have the NumPy fork working:
|
However, |
## Summary This doesn't actually change any behaviors, but it does make it a bit easier to solve #4669, because we don't have to support "version narrowing" for the non-`RequiresPython` variants in here. Right now, the semantics are kind of muddied, because the `target` variant is _sometimes_ interpreted as an exact version and sometimes as a lower bound.
## Summary This is required to solve #4669, because the `Requires-Python` version can now vary across a resolution. For example, within certain forks, we might have a more narrow range, which would allow us to use distributions that would not be allowed for the global resolution. This should be fine because `requires-python` is part of the package metadata, so it should be consistent between files within a package version. As such, there shouldn't be any risk that we incorrectly prioritize distributions by omitting this information. (To be more specific, the risk is something like: we prioritize some wheel over a source distribution within a package-version, so we don't track the source distribution at all. Then, later, when we choose a candidate, we see that the wheel doesn't meet the `Requires-Python` requirement, even though the source distribution _would've_ met it. If files within a distribution could have varied support, this would be a real risk.)
With #4902 merged, it reverted the fix for this issue, so I'm re-opening. |
I have some difficulties with
numpy
(macOS, uv 0.2.18). With a requirements.inI cannot univeral-lock for Python >= 3.8:
Originally posted by @davidfritzsche in #4640 (comment)
The text was updated successfully, but these errors were encountered: