Narrow requires-python requirement in resolver forks
#4707
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
charliermarsh
force-pushed
the
charlie/req-python
branch
from
f4a7ef4
to
b6bf3f6
Compare
charliermarsh
force-pushed
the
charlie/python-enforcement
branch
from
76365de
to
109168a
Compare
charliermarsh
force-pushed
the
charlie/req-python
branch
2 times, most recently
from
25491ad
to
7191a09
Compare
charliermarsh
force-pushed
the
charlie/req-python
branch
from
7191a09
to
338ee08
Compare
charliermarsh
force-pushed
the
charlie/python-enforcement
branch
from
109168a
to
4438e47
Compare
charliermarsh
force-pushed
the
charlie/req-python
branch
from
338ee08
to
b3797db
Compare
konstin
approved these changes
Jul 2, 2024
Respect fork markers Also narrow on dependencies
charliermarsh
force-pushed
the
charlie/req-python
branch
from
b3797db
to
2305824
Compare
BurntSushi
added a commit
that referenced
this pull request
Jul 8, 2024
The PR #4707 introduced the notion of "version narrowing," where a Requires-Python constraint was _possibly_ narrowed whenever the universal resolver created a fork. The version narrowing would occur when the fork was a result of a marker expression on `python_version` that is *stricter* than the configured `Requires-Python` (via, say, `pyproject.toml`). The crucial conceptual change made by #4707 is therefore that `Requires-Python` is no longer an invariant configuration of resolution, but rather a mutable constraint that can vary from fork to fork. This in turn can result in some cases, such as in #4885, where different versions of dependencies are selected. We aren't sure whether we can fix those or not, with version narrowing, so for now, we do this revert to restore the previous behavior and we'll try to address the version narrowing some other time. This also adds the case from #4885 as a regression test, ensuring that we don't break that in the future. I confirmed that with version narrowing, this test outputs duplicate distributions. Without narrowing, there are no duplicates. Ref #4707, Fixes #4885
BurntSushi
added a commit
that referenced
this pull request
Jul 8, 2024
The PR #4707 introduced the notion of "version narrowing," where a Requires-Python constraint was _possibly_ narrowed whenever the universal resolver created a fork. The version narrowing would occur when the fork was a result of a marker expression on `python_version` that is *stricter* than the configured `Requires-Python` (via, say, `pyproject.toml`). The crucial conceptual change made by #4707 is therefore that `Requires-Python` is no longer an invariant configuration of resolution, but rather a mutable constraint that can vary from fork to fork. This in turn can result in some cases, such as in #4885, where different versions of dependencies are selected. We aren't sure whether we can fix those or not, with version narrowing, so for now, we do this revert to restore the previous behavior and we'll try to address the version narrowing some other time. This also adds the case from #4885 as a regression test, ensuring that we don't break that in the future. I confirmed that with version narrowing, this test outputs duplicate distributions. Without narrowing, there are no duplicates. Ref #4707, Fixes #4885
BurntSushi
added a commit
that referenced
this pull request
Jul 8, 2024
The PR #4707 introduced the notion of "version narrowing," where a Requires-Python constraint was _possibly_ narrowed whenever the universal resolver created a fork. The version narrowing would occur when the fork was a result of a marker expression on `python_version` that is *stricter* than the configured `Requires-Python` (via, say, `pyproject.toml`). The crucial conceptual change made by #4707 is therefore that `Requires-Python` is no longer an invariant configuration of resolution, but rather a mutable constraint that can vary from fork to fork. This in turn can result in some cases, such as in #4885, where different versions of dependencies are selected. We aren't sure whether we can fix those or not, with version narrowing, so for now, we do this revert to restore the previous behavior and we'll try to address the version narrowing some other time. This also adds the case from #4885 as a regression test, ensuring that we don't break that in the future. I confirmed that with version narrowing, this test outputs duplicate distributions. Without narrowing, there are no duplicates. Ref #4707, Fixes #4885
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Given:
When resolving for Python 3.8, we need to narrow the
requires-pythonrequirement in the top branch of the fork, becausenumpy >=1.26all require Python 3.9 or later -- but we know (in that branch) that we only need to solve for Python 3.9 or later.Closes #4669.