GeezerVison

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).

Local verification

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