Repository navigation
🐛 fix(uv): rank minor version junctions behind the concrete install on Windows - #170
Merged
Merged
Conversation
…Windows uv links each minor version at its newest patch install, cpython-3.15 pointing at cpython-3.15.0b3 for example, and tox-dev#112 ranks that link behind the install it points at because uv repoints it on the next patch release. On Windows uv creates these links as directory junctions, and Path.is_symlink() returns False for a junction on every Python version, so the link was never demoted there. For a prerelease the link parses as the final release and wins outright, and for an X.Y.0 install the two tie and the link wins on directory name order. The resolved-path dedup then drops the concrete install, so get_interpreter() and iter_interpreters() report the junction path, which moves the next time uv installs a patch release. PEP 514 discovery runs first and finds the concrete path for installs uv registered there, so this hits Windows users whose uv Python has no registry entry. Spot the link by comparing the name it resolves to with its own name instead. Path.resolve() follows symlinks and junctions alike on every supported version, so this needs no Windows-only API: os.path.isjunction only exists from 3.12 and the stat reparse tag constants are only defined on Windows.
Move the platform branch out of the test body so the test only states what it checks. Drop the test docstring; the source comment already explains why junctions need their own detection.
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.
On Windows, discovery in a uv store returned uv's minor version link (
cpython-3.15-windows-x86_64-none) instead of the concrete install it points at (cpython-3.15.0a7-windows-x86_64-none). 🐛 uv moves that link to the next patch release on upgrade, so callers that store the path, such as a virtualenv's base interpreter, end up pointing at a different Python later. #112 ranked these links behind their target, and the docs promise that order, but the ranking only held on POSIX.uv creates the links as symlinks on POSIX and as directory junctions on Windows, and a junction does not report as a symlink (Python only gained
os.path.isjunctionin 3.12). For a prerelease the link name parses as the final release and outranks the install; for anX.Y.0install the two tie and the link wins on name order. The uv store ranking now spots a link by checking whether the entry resolves to a directory with a different name, which works for symlinks and junctions on every supported Python without a platform branch.Installs that uv also registers under PEP 514 were mostly unaffected, since the registry lookup runs before the store. The fix matters for installs found only through the store, prereleases among them.