fix: correct python_versions() minimum for major-only and multiple lower bounds#1127
Open
Sanjays2402 wants to merge 1 commit into
Open
fix: correct python_versions() minimum for major-only and multiple lower bounds#1127Sanjays2402 wants to merge 1 commit into
Sanjays2402 wants to merge 1 commit into
Conversation
…wer bounds
nox.project.python_versions(pyproject, max_version=...) parsed the lower
bound from requires-python by looping over the SpecifierSet and breaking on
the first lower-bound specifier it saw, reading its minor version with
`spec.version.split(".")[1]`. This had two bugs:
1. Crash on a major-only version. A valid requires-python of ">=3" (which
PEP 440 defines as equivalent to ">=3.0") has no minor component, so
`"3".split(".")[1]` raised a cryptic `IndexError: list index out of range`
from this public helper.
2. Wrong result with multiple lower bounds. For ">=3.8,>=3.10" the effective
minimum is 3.10, but breaking on the first lower-bound specifier returned
3.8 as the minimum, so the result claimed support for 3.8 and 3.9 which the
metadata explicitly excludes. The output could even depend on specifier
iteration order.
Fix: collect every lower-bound (">", ">=", "~=") specifier's minor version,
treating a major-only version as minor 0, and use the maximum as the
effective minimum. If there is no lower-bound specifier at all, the existing
ValueError is still raised.
Added regression tests for the major-only and multiple-lower-bound cases.
This file contains hidden or 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
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
nox.project.python_versions(pyproject, max_version=...)reads the lowerbound of supported Python versions from
requires-python. It looped over theSpecifierSetand broke on the first lower-bound specifier it encountered,reading the minor version with
spec.version.split(".")[1]. That logic has twobugs:
1. Crash on a major-only version
A valid
requires-python = ">=3"(equivalent to">=3.0"per PEP 440) has nominor component, so
"3".split(".")[1]raises a crypticIndexErrorstraightout of this public helper:
2. Wrong result with multiple lower bounds
For
requires-python = ">=3.8,>=3.10"the effective minimum is 3.10, butbreaking on the first lower-bound specifier returns 3.8, so the result claims
support for 3.8 and 3.9 which the metadata explicitly excludes:
The output could even flip depending on specifier iteration order.
Root cause
Both symptoms come from the same block, which assumed (a) exactly one relevant
lower bound and (b) that a version string always has a
major.minorshape.Fix
Collect every lower-bound (
>,>=,~=) specifier's minor version,treat a major-only version as minor
0, and use the maximum as theeffective minimum. When no lower-bound specifier exists, the existing
ValueErroris still raised.requires-python">=3"IndexError['3.0', …, max]">=3.8,>=3.10"(max3.12)['3.8','3.9','3.10','3.11','3.12']['3.10','3.11','3.12']">=3.10,>=3.8"(max3.12)['3.10','3.11','3.12']">=3.10"(max3.12)['3.10','3.11','3.12']">3.2.1,<3.3"(max3.4)['3.2','3.3','3.4']"==3.3.1"ValueErrorTests
Added
test_python_range_major_onlyandtest_python_range_multiple_lower_boundsto
tests/test_project.py. Verified they fail onmain(the first with theIndexError, the second asserting on the wrong['3.8', '3.9', …]output) andpass with the fix.
ruff checkandruff format --checkare clean on the changed files, and thechange introduces no new
mypyerrors (the 3 reported innox/project.pyarepre-existing and outside this diff).