GeezerVison

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

Fixes #765

Summary

A requirements.txt project vendored with one patch can now move to a newer patch for the same package. Before this, vendor, get <uuid> --mode vendored and scan --mode vendored all failed with pypi_requirements_already_vendored (exit 1, partial_failure). requirements.txt, the old uuid dir and the ledger stayed on the old patch, so pip kept installing it. Meanwhile --dry-run previewed would_revendor and CLI_CONTRACT said the package "is still re-vendored automatically".

Root cause

preflight_requirements (vendor/pypi_requirements.rs) treated a socket-patch vendor line for the package at a different patch uuid as a hard refusal. The CLI's re-vendor path (record_vendor_entry → sweep_stale_artifact) and the dry-run preview both expect the backend to re-wire in place, as npm, cargo, gem and pnpm do.

All the vendored PyPI writers have the same gap: uv (pypi_uv_source_already_exists, the vendored half of #742), Hatch (vendored half of #650), Poetry, PDM and Pipenv. This PR is the requirements.txt slice only. The other lanes are follow-ups. #742 and #650 stay open, and their hosted halves are in #743.

Fix

• New RequirementsTarget::Rewire. When requirements.txt already routes the package to an older uuid and the ledger holds exactly one pypi entry at that uuid whose records are all requirements_lines tagged name==version, the pre-flight plans a re-wire from that entry's own records (plan_rewire):
  • Each recorded vendor line is replaced in place by the new vendor line, keeping its environment marker, the tree's hash mode and the (transitive) note.
  • The new record keeps the old record's file, key, action and pre-vendor original. So vendor --revert of the new entry still restores the user's own pin byte for byte, and carry_forward_wiring has nothing to fill in.
• The re-vendor is still refused, before anything is written, when:
  • there is no such ledger entry (nothing records the pre-vendor original, so a re-wire could never be reverted),
  • a recorded line has drifted,
  • a recorded file has left the tree or the project root,
  • or the tree holds a vendor line for the package that the ledger did not record.
• The write loop is factored into write_plan and shared by wire_requirements and rewire_requirements. It keeps the symlink refusal and the partial-write unwind.
• The CLI is unchanged. The ledger entry is replaced, and the old uuid dir is removed (vendor_stale_artifact_removed).

Tests (red → green)

Local runs:

• cargo fmt --all -- --check: clean.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: 9727 passed, 12 failed, 253 ignored. All 12 failures are chmod-denial tests that cannot fail under root, which is what this sandbox runs as: *_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root, wire_failure_rolls_back_already_written_files and others. Re-run as the unprivileged nobody user, every one of them passes. That includes the requirements write-unwind test that write_plan now serves.
• mode_migration_pypi: 13/13.
• The npm, pypi and gem wrappers are untouched (the change is in the Rust vendor backend only).

Follow-ups (not in this PR)

• Vendored re-vendor to a superseding uuid for uv (uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742), Hatch (Hatch never picks up a superseding patch: re-scan refuses its own earlier wiring ("existing direct source must be reverted"), so hosted exits 0 still pinned to the old patch uuid #650), Poetry, PDM and Pipenv. Each backend's guard refuses an older uuid the same way, and the same ledger-driven re-wire pattern applies.

🤖 Generated with Claude Code

Generated by Claude Code