Skip to content

Comments

Narrow requires-python requirement in resolver forks#4707

Merged
charliermarsh merged 2 commits intomainfrom
charlie/req-python
Jul 2, 2024
Merged

Narrow requires-python requirement in resolver forks#4707
charliermarsh merged 2 commits intomainfrom
charlie/req-python

Conversation

@charliermarsh
Copy link
Member

Summary

Given:

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

When resolving for Python 3.8, we need to narrow the requires-python requirement in the top branch of the fork, because numpy >=1.26 all 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.

@charliermarsh charliermarsh added the bug Something isn't working label Jul 1, 2024
@charliermarsh charliermarsh changed the base branch from main to charlie/python-enforcement July 1, 2024 20:43
@charliermarsh charliermarsh force-pushed the charlie/python-enforcement branch from 76365de to 109168a Compare July 1, 2024 21:06
@charliermarsh charliermarsh force-pushed the charlie/req-python branch 2 times, most recently from 25491ad to 7191a09 Compare July 1, 2024 21:08
@charliermarsh charliermarsh force-pushed the charlie/python-enforcement branch from 109168a to 4438e47 Compare July 1, 2024 22:25
Base automatically changed from charlie/python-enforcement to main July 2, 2024 12:15
Respect fork markers

Also narrow on dependencies
@charliermarsh charliermarsh enabled auto-merge (squash) July 2, 2024 12:16
@charliermarsh charliermarsh merged commit d9f389a into main Jul 2, 2024
@charliermarsh charliermarsh deleted the charlie/req-python branch July 2, 2024 12:23
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

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Narrow requires-python in forks

2 participants