Pin the uv release toolchain and commit the lock in its marker normalization - #9444
Merged
Merged
Conversation
…ization The first automatic version bump after #9428 failed closed in the release lock guard: "Versioning changed the reviewed dependency graph". The runner installs the latest uv (0.12.13, unpinned) while the committed lock was written by 0.11.7. A fresh lock is left alone by either version, but the bump forces a re-resolution, and 0.12.13 then rewrites 37 resolution-marker lines in its own normalization; the guard compares the whole graph and refuses. Reproduced locally with uv 0.12.13 at version 2.0.0; under 0.11.7 the same refresh changes only the root version. Commit the lock as 0.12.13 writes it after a re-resolution (bump, lock, restore, lock: 37 marker lines change, no package or version changes), and pin uv 0.12.13 in every setup-uv step of the push, pull request and weekly lock workflows so the toolchain that checks the lock is the one that wrote it. With this lock the 2.0.0 refresh differs from the committed graph in the root version alone, by the guard's own comparison. uv 0.11.7 still passes `uv lock --check` on it, so developers need no upgrade. The release-lock document records how to move the pin. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
Why
The first automatic version bump after #9428 (push run 34657438359) failed in
Update versioningatpython .github/release_lock.py --refresh:The runner installs the latest uv (0.12.13; setup-uv found no pin and fell back to latest) while the committed lock was written by uv 0.11.7. A fresh lock is left alone by either version (
--committedpassed on the same runner minutes earlier), but the bump forces a re-resolution, and 0.12.13 then rewrites 37 resolution-marker lines in its own normalization (for examplepython_full_version < '3.12'markers on the sphinx tree). The guard compares the whole graph minus the root version and refuses, as designed. Reproduced locally: uv 0.12.13 at version 2.0.0 rewrites 38 lines; uv 0.11.7 rewrites the root version alone.What
uv.lock: regenerated by uv 0.12.13 after a forced re-resolution (bump the root version, lock, restore it, lock). 37 marker lines change; no package, version, hash or source changes. Root version stays 1.825.2.version: "0.12.13"on all 22astral-sh/setup-uvsteps inpush.yaml,pr.yaml,weekly-uv-lock.yaml, so the uv that checks and refreshes the lock is the one that wrote it..github/release-lock.md: how to move the pin (change it in all three workflows and regenerate the lock the same way in one reviewed PR).Verification
uv lockcommand under uv 0.12.13 leaves the graph identical except the root version, byrelease_lock.without_root_versioncomparison (the guard would pass).uv lock --checkunder uv 0.11.7 and 0.12.13 both pass on this lock and leave it unchanged..github/tests/test_release_lock.py: all pass.Merging this re-triggers the push workflow on main; its versioning job should now bump to 2.0.0 and publish.
🤖 Generated with Claude Code