[Mikola Lysenko (mikolalysenko)]

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

Fixes #981

Summary

After scan --mode vendored on a Pipenv project, pipenv requirements --hash > requirements.txt && pip install -r requirements.txt fails outright: the vendored wheel line has no --hash, every other line does, and pip's hash-checking mode refuses the whole install. Before this PR the CLI exited 0 with no warning, and the docs listed pipenv requirements as supported.

Vendored Pipenv runs now warn pypi_pipenv_hash_export_unsupported whenever the export would break. The warning names the vendored package, a hashed entry that turns hash checking on, and the two remedies: export without --hash, or use --mode hosted, whose #sha256= URL exports a hash pip accepts. The limitation is documented in docs/testing/pipenv-compatibility.md, docs/ecosystems.md and the CLI contract warning table.

Root cause

Pipenv 2023.7.9 and later never print --hash for file / path lock entries when exporting (the bisect on #981 pins the release). A vendored Pipfile.lock routes the patched package through a relative file entry, so this can't be fixed in the lock: the bisect found that a #sha256= fragment on the relative path breaks pipenv sync. The only correct fix on our side is to tell the user, the same way vendor_integrity_unverified and pypi_pipenv_stale_install cover Pipenv's other gaps.

When it warns

• Some other lock entry, in any category, is a hashed registry entry (non-empty hashes, no file/path/VCS/editable key). Without one, the export has no --hash line and pip never turns hash checking on.
• On a fresh wire and on an in-sync re-run (the gap outlives the first run, like the stale-install warning).
• Not when the probed Pipenv is 2022 or older: 2022.12–2023.6 export file:///<abs> --hash=…, and earlier releases have no requirements command.

Review findings not changed (/code-review high)

• Category scoping (warns when the only hashed sibling is in develop, though plain pipenv requirements exports only default): not changed. --dev and --categories exports combine categories, and those exports do fail, so the warning is right for the common Docker recipe that installs dev deps. The message says "an export holding both".
• Multi-package runs (with every hashed entry in the lock being vendored in the same run, the early packages still see later targets as hashed): not changed. This needs every registry dependency of the project to be patched at once, and handling it would mean passing the run's full target set into each per-package wiring. A spurious warning in that case costs much less than that plumbing.

Test evidence

Red → green regression tests for #981:

• vendor::pypi_pipenv::tests::hash_export_warning_when_other_entries_are_hashed failed against a stub that never warns (panicked at pypi_pipenv.rs) and passes with the fix. It covers a hashed sibling in the same category, one in develop, the message contents, and installer gating (2026 warns, 2022 doesn't).
• vendor::pypi_pipenv::tests::hash_export_warning_absent_without_other_hashed_entries: the target alone, and a sibling that is itself a file entry.
• vendor::pypi::tests::pipenv_vendor_warns_the_hash_export_gap (orchestrator, mock patch service) failed with the call site removed and passes with it. It covers a lone target (no warning), a hashed develop sibling (warns, lock wired), an in-sync re-run (still warns), and a pinned Pipenv 2022 (no warning).

Local gates at 958a972:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib pipenv: 116 passed
• cargo test --workspace --all-features --no-fail-fast: 14,978 passed, 11 failed, all environmental and none in Pipenv code: 9 write-failure fixtures that rely on chmod 0o555, which root (this sandbox runs as uid 0) bypasses (pypi_requirements/pypi_poetry wire-failure, copy_tree, vlt_heal, the repair/redirect write-failure CLI tests), and 2 e2e_bun_lockb tests that reach patches-api.socket.dev, which the sandbox proxy blocks. CI runs as non-root with network
• The pypi Docker e2e (docker_e2e_vendor_pypi_pm) needs a Docker daemon this sandbox lacks, so CI runs it. Its fixture locks only six, so the new warning doesn't fire there.

Per-issue checklist:

• Vendored Pipenv lock breaks pipenv requirements --hash | pip install -r on Pipenv 2023+: the vendored wheel is exported without a hash, so pip's hash-checking mode refuses the whole install #981: pypi_pipenv_hash_export_unsupported warning plus docs; tests listed above. The issue asked for a real export fix if one exists. None does (see the bisect), so it's covered as a documented limitation with a warning, which the issue named as the expected outcome.

No wrapper (npm/, pypi/, gem/) changes: they pass warnings through unchanged.

https://claude.ai/code/session_011qh1KydriBiRyb8hiHmfrw

---

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 958a972. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: Ready for review at 958a972.

• CI: 88/88 checks on 958a972 passed or skipped (38 success, 50 skipped); mergeable, no conflicts. No main-wide failures.
• Bugbot: reviewed 958a972, no findings; 0 open review threads.
• Already approved by a human at this head. Reviewer focus: the new Pipenv warning text and the CLI_CONTRACT.md / docs wording about --hash export behavior.

---

Generated by Claude Code