GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #979
Refs #944 (only its remaining dry-run preview piece; that issue stays with #963's claim)

Summary

On a uv project whose [tool.uv] or [tool.uv.sources] is written as an inline table, vendor --dry-run previewed a clean vendor (exit 0), but the real run refused with pypi_uv_lock_parse_failed (exit 1), and only after downloading the prebuilt wheel. With this PR the dry run previews the same refusal, and the real run refuses before any download or write.

Root cause

The uv vendored backend can't add keys to a [tool], [tool.uv] or [tool.uv.sources] that is an inline table or a non-table value, so it refuses with pyproject.toml [<path>] is not a standard table. That refusal was raised only by ensure_table inside wire_uv. The preflight check_target_guards, which pypi.rs runs before the prebuilt download and before the dry run returns, never checked the table chain.

Fix

• check_target_guards (crates/socket-patch-core/src/vendor/pypi_uv.rs) now runs a read-only check_standard_tables over the same chain wire_uv edits, in the same order: tool.uv for a transitive package (the override-dependencies path), then tool.uv.sources. It returns the same code and detail. A missing link is fine (wire creates it). Header-less tables implied by a sub-table and dotted-key tables (uv.package = true) still count as standard tables and stay wireable.
• ensure_table and the preflight share one not_a_standard_table constructor, so the two messages can't drift apart.
• Applies to vendor, scan --mode vendored and get --mode vendored, because all of them go through the same pypi.rs preflight. It also gives Keep the hosted pin when a vendored takeover is refused (#853, #944) #963's takeover dry-run preview the uv inline-sources gate that uv scan/get dry-run does not predict a refused hosted-to-vendored takeover #944 still needs.

CI fix carried for main: stale digest pending list

main (db83f01) is red on test (macos/windows), test-release and coverage. utils::digest::tests::production_digests_go_through_the_helpers fails because #690 moved crawlers/gradle_cache.rs, patch/jvm_jar.rs and patch/sidecars/maven.rs onto the utils::digest helpers but left them on PENDING_INLINE_DIGESTS, and the guard fails on a stale entry. This PR's earlier port of #878 (Route Gradle digests through utils::digest) is now a no-op after merging main. Commit d456e5b drops the three stale entries. It is test-only and no-ops once main carries the same change. Other open PRs based on main will hit the same failure until it does.

Reproduced on main 1c6c509 locally: the guard test fails with left = the 6 real inline files, right = those 6 plus the 3 Gradle files. After d456e5b it passes, and CI coverage and test (macos-latest) are green on ef589a6.

Test evidence

Red before the fix, on main + tests only:

• vendor::pypi_uv::tests::guards_refuse_non_standard_uv_tables_like_wire failed with unwrap_err() on an Ok value: Fresh (the preflight accepted the inline table).
• vendor::pypi::tests::uv_inline_sources_table_refused_in_dry_and_wet_runs failed with dry_run=true: expected Refused, got Done { … success: true … vendor_prebuilt_downloaded … }. This reproduces the issue: the dry run reported success.

Green after the fix: both pass.

Per-issue checklist:

• Vendored vendor --dry-run previews success on a uv project with an inline [tool.uv] / sources table, but the real run refuses pypi_uv_lock_parse_failed (exit 1) #979 inline [tool.uv] sources = {…}: unit test (preflight == wire error, files untouched) plus an orchestrator test (dry and wet runs both Refused pypi_uv_lock_parse_failed, no .socket/vendor dir, pair byte-identical)
• Vendored vendor --dry-run previews success on a uv project with an inline [tool.uv] / sources table, but the real run refuses pypi_uv_lock_parse_failed (exit 1) #979 [tool] uv = { sources = {…}, index = […] }: unit test
• Vendored vendor --dry-run previews success on a uv project with an inline [tool.uv] / sources table, but the real run refuses pypi_uv_lock_parse_failed (exit 1) #979 dotted [tool] uv.sources = {…}: unit test
• Vendored vendor --dry-run previews success on a uv project with an inline [tool.uv] / sources table, but the real run refuses pypi_uv_lock_parse_failed (exit 1) #979 transitive + [tool] uv = { constraint-dependencies = […] } names [tool.uv]: unit test
• standard, header-less and dotted tables are still wireable: unit test

Local runs (Linux, toolchain 1.93.1, on the merge with main db83f01):

• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: everything passes except 12 tests that make a path read-only (0o555) or unremovable and expect a write to fail. This container runs as root, and root ignores those permissions: covgap_commands_vendor::{vendor,revert,reconcile}_state_write_failure_*, 3 in_process_redirect write-failure tests, 2 repair cleanup-failure tests, copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_* and pypi_requirements::wire_failure_rolls_back_already_written_files. None of them touch this change, and CI runs as a non-root user.
• cargo fmt: the changed files are rustfmt-clean.
• Wrapper tests (npm/, pypi/, gem/): not affected. This is a Rust-only change.

Why this cluster

#979 was the only untriaged issue this run, and its fix is small and self-contained. It also closes the preview gap that #963 leaves open on #944, so one change helps two issues.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S9NhAHzAgkz5oUuRrbkyV3

Generated by Claude Code