Fix vendored Pipenv pylock.toml co-wiring (#1368)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1368

Summary

With [pipenv] use_pylock = true, pipenv lock writes a pylock.toml beside Pipfile.lock. PEP 751 installers (uv pip install -r pylock.toml, pip) install from it. Vendored mode now wires that pylock to the same committed wheel as Pipfile.lock, so vendor --check and vex stop reporting contested wiring and installs from the pylock get the patched package.

This finishes #1368: its uv-export lane was fixed by #1390, and this PR covers the remaining Pipenv pylock lane.

Root cause

detect_pypi_flavor routed a Pipenv project with both locks to Pipfile.lock (#1122), and named a pylock that pins the package as a pypi_multiple_lockfiles loser. Nothing ever wired it, so the "rewire both locks" remedy looped. Pipenv co-wiring (#1309, #1390) covered only an exported requirements.txt.

Change

• pypi_lock::pipenv_pylocks classifies each Pipenv pylock that holds the package: on the registry (wirable), already on a vendored wheel (with its uuid), or unwirable (a symlink, a non-registry source). Hatch-derived locked-env pylocks are left out.
• Fresh vendor: the pylock is wired through the python-lock backend after Pipfile.lock and before the requirements export. Its records sit in the same ledger entry (python_lock_document). A refusal puts back every file already written.
• Re-run over an already wired Pipfile.lock: a pylock made since is wired to the committed, verified wheel and recorded once. A re-lock replaces the old record instead of adding a second one.
• Superseding patch: the old entry's pylock records are reverted first, then the pylock is wired fresh, so the pre-vendor text carries forward. If that pylock drifted, the run refuses (as a drifted Pipfile.lock already does), and --dry-run predicts that refusal.
• Revert: the export and the pylocks are reverted before Pipfile.lock, and put back if any later revert fails or drift-keeps. The tree never ends up half reverted.
• A pylock that is unwirable, or that points at another patch's wheel that no ledger entry records, is still named in pypi_multiple_lockfiles.
• Dry run previews the wiring (pypi_pipenv_pylock_wired).
• Repair reads a Pipenv entry's Pipfile.lock fragment directly, so a pylock record can't hide it.
• Docs updated: the CLI_CONTRACT pypi_multiple_lockfiles row and the pipenv-compatibility table.

Test evidence

Red on unchanged code (cargo test -p socket-patch-core --lib -- vendor::pypi::tests::pipenv_: 6 failed), green with the fix:

Test	Covers
pipenv_vendor_wires_the_pipenv_pylock	fresh vendor wires pylock (with and without an export); discovery uncontested; revert restores byte for byte
pipenv_pylock_dry_run_previews_the_wiring	dry-run preview, nothing written
pipenv_in_sync_rerun_wires_a_later_pylock_once	pylock made after vendoring; re-lock replaces the record
pipenv_superseding_uuid_rewires_the_pylock	supersede re-wires; revert restores registry
pipenv_pylock_revert_keeps_both_wired_when_the_lock_fails	no half revert on lock failure
pipenv_pylock_beside_pipfile_lock_routes_to_pipenv (updated) / pipenv_use_pylock_project_vendors_into_pipfile_lock (updated)	no loser warning; pylock wired and reverted
pipenv_symlinked_pylock_beside_pipfile_lock_is_a_loser	unwirable pylock still named
pipenv_pylock_probe_skips_a_fifo_hatch_file, pipenv_pylock_on_an_unrecorded_patch_is_named, pipenv_superseding_uuid_refuses_a_drifted_pylock_in_dry_run_too, pipenv_pylock_drift_keeps_every_file_wired, pipenv_leaves_a_hatch_locked_env_pylock_alone	review hardening
recover_pypi_urlless_locks_report_no_fetchable_url (extended)	repair with a pylock record in either order
e2e pipenv::pipenv_pylock_projects_wire_what_pipenv_installs (real Pipenv 2026.8.0)	pylock wired; fresh pipenv install --deploy patched; uv pip install -r pylock.toml installs the patched six

Commands run locally:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features --lib: 6306 passed. 4 failed, and the same 4 fail on main in this sandbox because they rely on file permissions that root bypasses (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_*, pypi_requirements::wire_failure_rolls_back_*).
• cargo test -p socket-patch-cli --all-features --test mode_migration_pypi: 58 passed
• SOCKET_PATCH_PIPENV_E2E_REQUIRED=1 SOCKET_PATCH_PIPENV_E2E_VERSIONS=2026.8.0 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- pipenv:: --ignored: 2 passed
• A full cargo test --workspace ran out of the sandbox's disk while linking. CI runs the full matrix.

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

/code-review high findings not fixed

• When pylock wiring fails, the whole Pipenv vendor fails instead of falling back to a loser warning. This matches how the requirements export (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) and Pipfile.lock refusals already work: fail closed, with every file restored.
• When the superseded pylock drifted, the upgrade refuses. This is the same policy as a drifted Pipfile.lock (pipenv_superseding_uuid_drifted_entry_refuses). The old entry holds the only pre-vendor originals.
• The pylock set is recomputed a few times per package. Pipenv projects have one or two small pylocks, so I kept the plan and the wiring each reading the live files.

Compatibility

An older binary reverting a Pipenv entry that has pylock records gives the python_lock_document records to the Pipfile.lock backend, which reports them as drifted and keeps the entry. That is the ledger's documented forward-compatibility behavior.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WU8SL8CcLJsyMHUF4HRaTn

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[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 b5a3675. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at b5a3675.

• CI: 35/35 non-skipped checks green (19 skipped).
• Bugbot: reviewed b5a3675, no findings.
• Mergeable: yes, no conflicts with main. Already approved by Tanmay Singla (@Tanmay182003) at this head.
• Slack announcement not sent: the Slack send tool was unavailable this run, so the next run will retry.

---

Generated by Claude Code