Fix vendored Pipenv sibling requirements.txt (#612)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #612 (the requirements.txt lanes). The Pipenv pylock.toml and uv-export lanes from the issue comments are split out to #1368.

Summary

A Pipenv project often installs through a pipenv requirements > requirements.txt export, for Docker or plain pip. Before this PR:

• Vendored mode wired only Pipfile.lock, so that path kept installing the unpatched release. Decide which lockfile governs installs in one table #1044 made this loud, but it was still unpatched.
• The hosted → vendored takeover turned the export's hosted pin back into a plain PyPI pin.
• Re-running vendor answered already_vendored, so vendor --check and vex (whose remedy says "re-run vendor") stayed red.

Root cause

The vendored flavor router picks one flavor (pipenv), and only that flavor's file is wired. The exported requirements pin was only ever named as a pypi_multiple_lockfiles loser.

Fix (core vendor/pypi.rs, vendor/pypi_requirements.rs)

• sibling_pin_wirable checks whether the requirements set (root requirements.txt and in-root -r includes) pins the package exactly from the registry, in a shape the requirements wiring rewrites in place. It never appends a line. When it does, the Pipenv plan also rewrites that pin to the same committed wheel (hashed or not, following the file), and the records go into the same ledger entry. If the requirements write fails after the lock was written, Pipfile.lock is put back.
• Routing no longer names such a pin a loser beside Pipfile.lock. A pin the wiring can't rewrite (a range, extras, an include outside the root) stays loud.
• Revert (vendor --revert, remove, rollback, the takeover): records are split by kind. Pipfile.lock records go through revert_pipenv and requirements_line records through revert_requirements, so both files come back.
• Superseding re-vendor: a superseded entry's recorded requirements lines are re-wired in place to the new uuid.
• In-sync re-run (a project vendored before this change, or an export made since): the export is wired to the committed wheel and the ledger entry is extended (pypi_requirements_sibling_wired). Without a ledger entry it stays a named loser.
• CLI_CONTRACT.md (pypi_multiple_lockfiles row) and docs/testing/pipenv-compatibility.md are updated.

Coordination: another session pushed a parallel attempt to this branch (872c692, c17e5d8) while this one was finishing. d3f6c30 merges it: it keeps this branch's implementation, which also covers the CLI e2e, the in-sync re-run, supersede and docs items that attempt listed as remaining, and carries over its core test. Pipfile.lock writing is untouched apart from making LOCK_FILE pub(super), so this shouldn't conflict with #1188.

Tests (per issue)

• Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 CLI (real binary, hermetic): mode_migration_pypi::pipenv_vendor_wires_the_exported_requirements_too covers a fresh vendor, an export reached through -r req/base.txt, an export added after a first vendor (the re-run wires it), and the hosted → vendored takeover. In each case both files point at the vendored wheel, vendor --check exits 0, and the revert restores the export byte for byte and Pipfile.lock semantically.
• pipenv_hosted_to_vendored_keeps_the_requirements_patched: the Decide which lockfile governs installs in one table #1044 takeover test now asserts the new contract (export vendored, nothing UNPATCHED).
• Core: pipenv_vendor_wires_the_exported_sibling_requirements (from the parallel attempt). Discovery finds both files with nothing contested, and the revert is byte-identical. requirements_beside_the_governing_lock_is_a_loud_loser was updated (Pipenv's wirable export is quiet, a range stays loud).

Red→green: before the fix the CLI test failed on the vendor envelope's "requirements.txt will still install the UNPATCHED" warning.

Commands run

• cargo test -p socket-patch-core --lib: all pass. vendor::pypi is 415 tests.
• cargo test -p socket-patch-cli --all-features --no-fail-fast: all pass except two e2e_vendor_cargo_build old-toolchain cells. Those fail locally with Bad CPU type in executable (an x86 rustup toolchain on arm64), a host issue.
• cargo clippy --workspace --all-features -- -D warnings and cargo fmt --check: clean for the changed files.

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches PyPI vendored wiring, revert, and ledger semantics for Pipenv; mistakes could leave mixed patched/unpatched install paths or partial reverts.

Overview
Vendored Pipenv now patches the common pipenv requirements > requirements.txt install path alongside Pipfile.lock, matching hosted mode. Exact registry pins in the root file or in-root -r includes are rewritten to the same .socket/vendor/pypi/<uuid>/ wheel, recorded on one ledger entry, and restored together on vendor --revert. Pins that cannot be rewritten (ranges, etc.) still trigger pypi_multiple_lockfiles.

Behavior changes: hosted→vendored takeover no longer leaves the export on plain PyPI; in-sync re-runs extend the ledger and wire a late-added export (pypi_requirements_sibling_wired); supersede re-vendors re-wire prior requirements lines; failed sibling wiring rolls back Pipfile.lock.

Collateral: production e2e/backtest harnesses pin a new free minimist@1.2.2 patch UUID and updated patched hash; vlt backtest holds() resolves patch file paths with or without a package/ prefix. Docs (CLI_CONTRACT.md, pipenv-compatibility.md) and tests cover the new contract.

^{Reviewed by Cursor Bugbot for commit d3f6c30. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Merged the parallel attempt (872c692, c17e5d8) instead of force-pushing. This branch's implementation covers the items that attempt listed as remaining, and its core test is kept. The pylock and uv lanes moved to #1368.

[Mikola Lysenko (mikolalysenko)]

BugBot review

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issues.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d3f6c30. Configure here.}