Skip to content

Fix Python version resolution for exact patch version matches#17828

Closed
jonathan-fulton wants to merge 1 commit intoastral-sh:mainfrom
jonathan-fulton:fix/python-version-prerelease-16175
Closed

Fix Python version resolution for exact patch version matches#17828
jonathan-fulton wants to merge 1 commit intoastral-sh:mainfrom
jonathan-fulton:fix/python-version-prerelease-16175

Conversation

@jonathan-fulton
Copy link

Summary

Fixes #16175

The prerelease filtering for MajorMinorPatch version requests was inconsistent with Range version matching behavior. When a user requested a specific version like 3.14.0, the code would reject 3.14.0rc3 even if no stable release was available.

Changes

Removed the strict prerelease rejection for exact patch version matches in crates/uv-python/src/discovery.rs.

Rationale

This makes behavior consistent with range matching which already handles prereleases appropriately. During Python's prerelease cycles (like Python 3.14), users should be able to request specific versions and get prerelease versions if no stable release is available yet.

The previous behavior was overly strict and inconsistent with how range specifications work:

  • >=3.14 would match 3.14.0rc3
  • 3.14.0 would NOT match 3.14.0rc3

After this change, both behave consistently.

Test Plan

  • Verified the change compiles successfully
  • Confirmed the logic aligns with the existing range matching behavior

…-sh#16175)

The prerelease filtering for MajorMinorPatch version requests was
inconsistent with Range version matching behavior. When a user requested
a specific version like 3.14.0, the code would reject 3.14.0rc3 even if
no stable release was available.

This change removes the strict prerelease rejection for exact patch
version matches, making behavior consistent with range matching which
already handles prereleases appropriately.

This allows users to get prerelease versions when requesting specific
versions if no stable release is available, which is the expected
behavior during Python's prerelease cycles.

Fixes astral-sh#16175
@zanieb
Copy link
Member

zanieb commented Feb 3, 2026

The issue you link to is already closed and I'm not sure what the motivation is for this change.

We intentionally made this change in #16210 and I think the way that you've described the current behavior makes sense to me?

Can you please open an issue describing the use-case as a starting point?

@zanieb zanieb closed this Feb 3, 2026
@jonathan-fulton
Copy link
Author

Thanks for the feedback @zanieb! I should have checked that the issue was already closed and that this behavior was intentional per #16210. Apologies for not doing my homework first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Question/Bug: Can't specify exactly 3.14.0 as the Python version

2 participants