Repository navigation
Fix hosted uv missing uv<0.5.6 advisories (#1569) - #1609
Mikola Lysenko (mikolalysenko) wants to merge 5 commits into
Conversation
Assisted-by: Claude Code:claude-opus-5-5
A hosted uv scan wires a transitive patched package through a marked override-dependencies entry, and repoints [manifest] constraints in uv.lock. uv before 0.5.5 honours neither: a plain uv sync silently reinstalls the unpatched wheel, or uv sync --locked fails. Vendored mode already warns about both; hosted printed nothing and exited 0. Hosted scans now emit redirect_uv_override_requires_uv_0_5_6 and redirect_uv_constraints_require_uv_0_5_6 on the run that wires those shapes (project and script locks). They advise only: the redirect still counts and the exit code is unchanged. Fixes #1569 Assisted-by: Claude Code:claude-opus-5-5
Re-bless the uv rewrite golden: the only change in its 1500 seeded cases is the new advisory (verified by filtering those two codes and matching the previous golden exactly), and require that the sweep reaches both codes. The real-uv hosted transitive and constraints lanes now assert the advisory, and the uv_hosted transitive case expects it. Refs #1569 Assisted-by: Claude Code:claude-opus-5-5
Review fixes for the hosted uv advisories: - A user's own override-dependencies entry, which the hosted rewrite reuses for its source, now gets the advisory too: old uv ignores the source there just the same. - Read the [manifest] constraints from the lock session's document instead of parsing the lock again per package. - Hosted and vendored now share one advisory text, which names the real affected range (uv before 0.5.5) and the canonical name. - Vendored-to-hosted takeover no longer names a uv advisory as the reason another package stayed vendored. Refs #1569 Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
The takeover's skip explanation matched a warning that names the package before it filtered out landed-pin advisories, so a package named like a word in the uv advisory (wheel, uv, sync) could inherit another pin's advisory as its reason for staying vendored. Filter the uv advisories out of both passes. Refs #1569 Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 21f5d28. Configure here.
|
Ready for review at 21f5d28: CI 35/35 green (19 skipped), no conflicts, Bugbot reviewed this head with no findings and the one earlier review thread is resolved. Reviewers: the new hosted advisories Generated by Claude Code |
|
[agent] I verified this PR (head
No issues found. Generated by Claude Code |
LLM Description written by Claude Code:claude-opus-5-5
Fixes #1569
Summary
A hosted uv scan can wire the patched package in two ways that uv before
0.5.5 doesn't honour:
[tool.uv] override-dependenciesentry plus a[tool.uv.sources]url. On old uv a plainuv syncre-resolves theoverride against the registry and silently reinstalls the unpatched
wheel.
constraint-dependencies: the lock's[manifest] constraints/build-constraintsentry is repointed, and old uv rejectsthat under
uv sync --locked.Vendored mode already warned about both (
pypi_uv_override_requires_uv_0_5_6,pypi_uv_constraints_require_uv_0_5_6). Hosted mode warned about neither andexited 0. Now hosted scans emit
redirect_uv_override_requires_uv_0_5_6andredirect_uv_constraints_require_uv_0_5_6when they write that wiring, forproject and PEP 723 script locks. These are advisories only: the redirect
still counts, the exit code doesn't change, and a settled re-run says nothing.
Root cause
rewrite_uv_lock(patch/redirect/mod.rs) confirms the pin without lookingat which wiring shape it used, so the uv-version advisories that
vendor/pypi_uv.rsemits for the same shapes had no hosted equivalent.Changes
rewrite_uv_lock: once a dep is confirmed and this run changed itswiring, check whether the paired pyproject/script reaches it through an
override (a marked entry or the user's own) and whether the lock's
[manifest]constrains it. The constraints check reads the lock session'sexisting parsed document, so the lock isn't parsed again.
utils/python_script.rs).The text now gives the measured affected range (uv before 0.5.5, per
docs/testing/uv-compatibility.md) and keeps the documented
>= 0.5.6advice. Before, the constraints text said only 0.2.37–0.5.3 were affected,
but 0.5.4 rejects the entry too.
UV_OLD_RELEASE_ADVISORIES: excluded from the "see the warning below"count and from the takeover's skip-reason lookup, because they describe a
pin that landed.
Test evidence
patch::redirect::uv_old_release_advisoriestests: transitiveoverride (LF and CRLF), repointed constraint, a user-written override
under a non-canonical
Sixgrant, script-lock override, and a silentdirect dependency. Before the fix: 3 failed (
left: [], expected thecode). After the fix: all pass.
python_lock_rewrite.goldenre-blessed. To check it, I filtered out thetwo new codes in the harness and matched the previous golden exactly
across all 1500 seeded cases. The sweep now has to reach both codes.
tests/uv_hosted.rs: the transitive case expects the override advisory.cargo test -p socket-patch-cli --all-features --test e2e_redirect_uv_build -- --ignored: 9/9 pass. The hosted transitive andconstraints lanes now assert their advisory, and every other lane asserts
that neither code appears.
cargo fmt --all -- --checkandcargo clippy --locked --workspace --all-features -- -D warnings: clean.cargo test -p socket-patch-cli --lib: 921 pass.cargo test --workspace --all-features --no-fail-fast: the onlyfailures were tests that can't pass in this sandbox, which runs as root
with no route to patches-api.socket.dev: chmod-based write-failure tests
(poetry/requirements wire rollback, repair cleanup, vlt heal, copy_tree
symlink) and the network-backed
e2e_bun_lockbrollback. None of themtouch uv. CI runs them as non-root.
Per-issue checklist
uv syncsilently reinstalls the unpatched wheel after a clean exit 0 #1569 transitive override lane →transitive_override_wiring_advises_uv_0_5_6,user_written_override_advises_uv_0_5_6,transitive_script_override_advises_uv_0_5_6, e2ehosted_uv_transitive_override_manifestless_vexuv syncsilently reinstalls the unpatched wheel after a clean exit 0 #1569 constraint lane →repointed_manifest_constraint_advises_uv_0_5_6, e2ehosted_uv_constraints_manifestless_vexBugbot
explaincould name a uv advisory as a package's skip reason through thenames_packagepass. Fixed in 21f5d28 with the regression testuv_old_release_advisories_never_explain_a_skip, which goes red to green.Review notes (/code-review high)
Fixed: user-written overrides were missed, takeover skip-reason list,
wrong version range in the text, non-canonical name, an extra lock parse,
duplicated text, and the e2e absence check. Not changed: re-emitting on a
re-pin to a superseding patch. That run rewrites the same fragile wiring, so
the advisory still applies; the contract now says so.
🤖 Generated with Claude Code
Generated by Claude Code