GeezerVison

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

Fixes #1136

Summary

A vendored Poetry (or PDM) project can now move to a newer patch for the same release. Before, when the patch API superseded patch A with patch B, scan --mode vendored and vendor failed with pypi_poetry_source_already_exists (or pypi_pdm_source_already_exists) and exit 1, while --dry-run promised would_revendor. The lock stayed on A, so every install kept getting the old patch. Now the re-vendor rewires the lock to B, sweeps A's artifact (vendor_stale_artifact_removed), and exits 0, as the CLI contract's scan --vendor paragraph promises.

Root cause

The PyPI vendored orchestrator (crates/socket-patch-core/src/vendor/pypi.rs) handles a superseding patch by routing a flavor guard's "already wired by an older socket-patch vendor" refusal through supersede_or_refuse. That replays the old ledger entry's revert, then plans a fresh wiring over the restored lock (#943 did this for uv, script locks and Hatch). The Poetry and PDM arms skipped it: they turned every check_target_guards error straight into a refusal, SUPERSEDABLE_REFUSALS had no Poetry or PDM code, superseded_files had no entry for them, and fresh_pyproject_plan could not re-plan either flavor.

Fix

• Poetry and PDM arms route a guard refusal through supersede_or_refuse, like uv/script-lock/Hatch.
• SUPERSEDABLE_REFUSALS gains pypi_poetry_source_already_exists and pypi_pdm_source_already_exists; superseded_files gains poetry.lock / pdm.lock; fresh_pyproject_plan gains Poetry and PDM arms.
• Unchanged safety: a user-authored source, old wiring with no ledger entry, or old wiring hand-edited since vendoring still refuses, with every file left byte-identical and no new uuid dir. These paths are covered by the existing ledgerless and drifted-wiring tests, now run for Poetry and PDM too.

PDM has no issue of its own. The #1136 reporter found the same gap in the PDM arm and handed it to the PDM routine. It is the same defect at the same boundary, so this PR fixes it too.

No wrapper changes are needed (npm/, pypi/, gem/ only dispatch to the binary).

Tests (red on main → green here)

Commands run locally

• cargo clippy --workspace --all-features -- -D warnings: clean.
• rustfmt --check on every touched file: clean. Note: cargo fmt --all -- --check flags files on main that this PR does not touch; CI has no fmt gate, so I left them alone.
• cargo test -p socket-patch-core --all-features --lib: 5772 passed, 4 failed. The same 4 also fail on main in this sandbox because it runs as root, so chmod-based write-failure tests don't trip: copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files. CI runs non-root and is green on main.
• mode_migration_pypi: 41/42. The 1 failure, pipenv_hosted_to_vendored_names_the_unpatched_requirements, needs pypi.org, which the sandbox can't reach; it fails the same way on main.
• in_process_vendor_pypi_takeover, hosted_superseding_pypi, in_process_redirect_poetry: all pass.
• e2e_vex_build -- poetry:: --ignored with real Poetry 2.4.3: both vendored tests pass. The hosted test fails on pypi.org access in the sandbox; it doesn't touch this code path.
• The full cargo test --workspace filled the sandbox disk, so I ran the suites above instead. CI runs the full set.

Follow-ups

• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (uv): a hosted → vendored takeover fails package_not_installed when the venv holds the old patch. That is a separate cause.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q9VebYpgWmCcMxocpcReMJ

Generated by Claude Code