Skip to content
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

Closed
charliermarsh opened this issue Jun 30, 2024 · 7 comments · Fixed by #4707
Closed

Narrow requires-python in forks #4669

charliermarsh opened this issue Jun 30, 2024 · 7 comments · Fixed by #4707
Assignees
Labels
bug Something isn't working preview Experimental behavior resolver Related to the package resolver

Comments

@charliermarsh
Copy link
Member

I have some difficulties with numpy (macOS, uv 0.2.18). With a requirements.in

numpy >=1.26; python_version>="3.9"
numpy <1.26; python_version<"3.9"

I cannot univeral-lock for Python >= 3.8:

$ uv pip compile -p 3.8 --universal requirements.in
  × No solution found when resolving dependencies:
  ╰─▶ Because only the following versions of numpy{python_version >= '3.9'} are available:
          numpy{python_version >= '3.9'}<=1.26.0
          numpy{python_version >= '3.9'}==1.26.1
          numpy{python_version >= '3.9'}==1.26.2
          numpy{python_version >= '3.9'}==1.26.3
          numpy{python_version >= '3.9'}==1.26.4
          numpy{python_version >= '3.9'}==2.0.0
      and the requested Python version (3.8) does not satisfy Python>=3.9, we can conclude that any of:
          numpy{python_version >= '3.9'}>=1.26.0,<1.26.2
          numpy{python_version >= '3.9'}>1.26.2,<1.26.3
          numpy{python_version >= '3.9'}>1.26.3,<1.26.4
          numpy{python_version >= '3.9'}>1.26.4,<2.0.0
          numpy{python_version >= '3.9'}>2.0.0
       are incompatible.
      And because the requested Python version (3.8) does not satisfy Python>=3.9 and you require
      numpy{python_version >= '3.9'}>=1.26, we can conclude that the requirements are unsatisfiable.

Originally posted by @davidfritzsche in #4640 (comment)

@charliermarsh charliermarsh added bug Something isn't working resolver Related to the package resolver preview Experimental behavior labels Jun 30, 2024
@charliermarsh
Copy link
Member Author

My guess is that numpy >=1.26 doesn't support Python 3.8, and we're still trying to lock for your requires-python in that branch. But in theory we could only require requires-python >= 3.9 in the numpy >=1.26 branch.

@charliermarsh
Copy link
Member Author

See also #4668 for another variant of this issue.

@charliermarsh
Copy link
Member Author

I can give this a try... Important correctness issue.

@charliermarsh charliermarsh self-assigned this Jul 1, 2024
@charliermarsh
Copy link
Member Author

This is pretty tricky because we build the VersionMap based on the Python requirement, but now the Python requirement can change in a given fork.

@charliermarsh
Copy link
Member Author

I have the NumPy fork working:

# This file was autogenerated by uv via the following command:
#    uv pip compile -p 3.7 --universal req.in
numpy==1.21.6 ; python_version < '3.9'
    # via -r req.in
numpy==2.0.0 ; python_version >= '3.9'
    # via -r req.in

@charliermarsh
Copy link
Member Author

However, echo 'uv;python_version>="3.8"' | uv pip compile -p 3.7 --universal - requires some more work...

charliermarsh added a commit that referenced this issue Jul 1, 2024
## 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.
charliermarsh added a commit that referenced this issue Jul 2, 2024
## 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.)
@BurntSushi
Copy link
Member

With #4902 merged, it reverted the fix for this issue, so I'm re-opening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working preview Experimental behavior resolver Related to the package resolver
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants