Fix vendored requirements.txt re-vendoring removed pins (#786)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #786

Root cause

dispatch_in_use_one (crates/socket-patch-cli/src/commands/vendor.rs) only has lockfile in-use probes for npm and cargo. For pypi it returns None ("can't tell"). The vendor-ledger discovery supplement and the scan --prune GC both treat None as "still wired". So when a user removes or bumps a vendored requirements.txt pin, the next vendored scan rediscovers the ledger entry. It then re-adds the package as a (transitive) line, or refuses with pypi_requirement_not_pinned on every run, and --prune never reverts the entry.

Change

• vendor::pypi_requirements::requirements_entry_in_use: for the requirements flavor, the requirements tree is the lock pip installs from. The probe reads the root requirements.txt plus every in-root -r include (the same walk the planner and the unwired-revert guard use).
  • Some(true) when a requirement line's code (not its comment) still names .socket/vendor/pypi/<uuid>/.
  • Some(false) when the tree was read and nothing does.
  • None (keep the entry, fail-safe) when no file could be read, or when a reached include exists but is unreadable.
• vendor::pypi::vendored_entry_in_use routes the requirements flavor to that probe. Every other pypi flavor still returns None. dispatch_in_use_one gains the pypi arm.

Tests (red → green)

• crates/socket-patch-cli/tests/scan_vendor_requirements_unwired.rs (built binary, mock patch API with no patches, seeded requirements-flavor ledger):
  • removed_vendored_pin_is_unwired_and_pruned (Vendored requirements.txt after the user removes or bumps a vendored pin: the rescan re-adds the removed package as a "(transitive)" line (exit 0), or exits 1 forever after a bump, and scan --prune never reverts the entry #786 case A) and bumped_vendored_pin_is_unwired_and_pruned (Vendored requirements.txt after the user removes or bumps a vendored pin: the rescan re-adds the removed package as a "(transitive)" line (exit 0), or exits 1 forever after a bump, and scan --prune never reverts the entry #786 case B). A plain rescan warns vendor_ledger_entry_unwired, exits 0, never sends the stale purl to the patch API and leaves requirements.txt untouched. --prune then reports the entry in gc.revertedVendoredEntries, exits 0, keeps the user's own pin and removes the uuid dir and the ledger entry.
  • wired_vendored_pin_stays_discoverable (control: the fresh-clone supplement still works).
  • Red without the fix: with the pypi arm removed from dispatch_in_use_one, both Vendored requirements.txt after the user removes or bumps a vendored pin: the rescan re-adds the removed package as a "(transitive)" line (exit 0), or exits 1 forever after a bump, and scan --prune never reverts the entry #786 tests fail at the vendor_ledger_entry_unwired assertion (0 warnings). The control passes either way.
• Core unit tests in pypi_requirements.rs: in_use_probe_sees_wired_vendor_lines (root pin, transitive line, -r include), in_use_probe_reports_removed_or_bumped_pins_unused (removed, bumped, commented-out, another uuid), in_use_probe_is_undeterminable_without_a_readable_tree (no requirements.txt, FIFO include).

Issue	Regression test
#786 case A (removed pin re-added as transitive)	removed_vendored_pin_is_unwired_and_pruned
#786 case B (bumped pin, exit 1 forever)	bumped_vendored_pin_is_unwired_and_pruned

Local verification

Command	Result
cargo clippy --workspace --all-features -- -D warnings	clean
cargo test -p socket-patch-core --all-features --lib	4845 passed. The 4 that fail as root (permission-denial fixtures: relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files) pass when re-run as an unprivileged user
cargo test -p socket-patch-cli --all-features --lib	834 passed
--test scan_vendor_requirements_unwired	3 passed
--test scan_requirements_lock_only	2 passed
--test scan_vendor_e2e	33 passed
--test e2e_vendor_pypi_build -- --include-ignored (uv 0.8.17, real pip)	23 passed
node --test npm/socket-patch/bin/socket-patch.test.mjs	passed

I couldn't run the full cargo test --workspace locally: building every test binary exceeds the session's disk allowance. CI runs it.

CI

All 475 checks are green on 580fff7, and Bugbot reviewed 580fff7 with no findings. The first attempt had three compatibility-matrix cells fail on paths this change can't reach, so I re-ran them once and all passed:

• Bun 1.3.0 preexisting-manifest vendored (refusalCodesExact, an 80s case).
• PDM 1.15.5 and 2.9.3 agent-mode rescanIdempotent.

The same jobs were green on other open PRs.

Notes

• The repo isn't cargo fmt-clean on main with the pinned toolchain, and CI has no fmt gate. cargo fmt --all rewrites about 130 unrelated files, so this PR carries only its own hunks, which are rustfmt-clean.
• Follow-ups (not claimed here): uv / poetry / pdm / pipenv / hatch / python-lock entries, and gem / golang / composer / nuget / maven, still have no in-use probe. They keep the fail-safe None.
• No wrapper changes are needed (npm/ only dispatches to the binary; the pypi and gem wrappers were dropped in v5).
• Picked ahead of older p1 issues because it's a correctness bug that silently re-adds a dependency the user removed, and the fix is small and self-contained.

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ 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 580fff7. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review — head 580fff7847e3.

• CI: 97/97 completed checks green (3 skipped by path filter); branch is up to date with main, no conflicts.
• Bugbot: reviewed 580fff7 — no findings. No unresolved review threads.
• Reviewer focus: the new pypi arm in dispatch_in_use_one returns None (keep entry) whenever the requirements tree can't be fully read, so --prune only reverts entries it can prove are unwired.

---

Generated by Claude Code