Repository navigation
fix(hooks): run the uv hooks with --locked so lock drift is loud - #82
Merged
Merged
Conversation
A bare `uv run` re-resolves and rewrites uv.lock whenever pyproject.toml has drifted from it. Inside a pre-commit hook that is destructive in a way that takes a while to see: the rewrite lands on a file the hook is not allowed to change, pre-commit stashes the commit, the auto-fix conflicts with the stash, and it rolls everything back with "Stashed changes conflicted with hook auto-fixes". The commit silently never happens, and uv.lock is left modified in the working tree. That is how the five Dependabot PRs could each leave the lock stale: locally the first commit attempt would have quietly repaired it. --locked stops the rewrite and, unlike --frozen, actually fails: measured on a drifted lock, `uv run --locked` exits 2 with "The lockfile at `uv.lock` needs to be updated, but `--locked` was provided", where `--frozen` exits 0 and proceeds against the stale lock. Drift now blocks the commit instead of being swallowed, matching the `uv lock --check` gate added to CI in d12e941. The two `--isolated --with ruff` invocations are left alone: --isolated ignores the project, so they never touch the lock.
Cipher208
enabled auto-merge (squash)
October 6, 2026 23:19
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
A bare
uv runre-resolves and rewritesuv.lockwheneverpyproject.tomlhas drifted from it. Inside a pre-commit hook that is destructive in a way that takes a while to see: the rewrite lands on a file the hook is not allowed to change, pre-commit stashes the commit, the auto-fix conflicts with the stash, and it rolls everything back withStashed changes conflicted with hook auto-fixes. The commit silently never happens, anduv.lockis left modified in the working tree. I lost two commits to this in this session before spotting it.That is also how the five Dependabot PRs (#71-#75) could each leave the lock stale: locally, the first commit attempt would have quietly repaired it.
Why
--lockedand not--frozenMeasured on a deliberately drifted lock (
alembic>=1.19.0against a locked 1.20.0):--frozen--locked--frozenstops the destructive rewrite but happily runs against a stale lock, so the drift stays invisible.--lockedstops the rewrite and fails, which is what makes it visible:Checked both directions: with a consistent lock the commit goes through and
git hash-object uv.lockis byte-identical before and after (no quiet rewrite); with drift the commit is blocked with exit code 1 and no stash-rollback.This matches the
uv lock --checkgate added to CI in d12e941, so local and CI now agree.The two
--isolated --with ruffinvocations inprepush-gateare deliberately left alone:--isolatedignores the project, so they never touch the lock.