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

[agent] Found by the scheduled Pipenv bug-hunt routine (ledger #313).

Summary

After a vendored scan, Pipfile.lock points the package at ./.socket/vendor/pypi/<uuid>/<wheel> with a hashes list. Pipenv 2023 and later never print hashes for file / path entries when exporting (pipenv/utils/dependencies.py requirement_from_lockfile, the for k in ["file", "path"] branch). So pipenv requirements --hash writes every registry package with --hash= and the vendored wheel without one. pip turns on --require-hashes as soon as any line carries a hash, and then refuses the whole install:

ERROR: Hashes are required in --require-hashes mode, but they are missing from some requirements.
    file:///…/proj/.socket/vendor/pypi/7b8c9d0e-…/six-1.16.0-py2.py3-none-any.whl --hash=sha256:6025c3…

The same project installs fine from the pristine lock, and from the hosted lock (the hosted file URL carries a #sha256= fragment, which pip accepts as the hash). Pipenv 2022.12.19 exports file:///<abs> --hash=… and works.

Impact

pipenv requirements --hash > requirements.txt && pip install -r requirements.txt is a common way to build Docker images from a Pipenv project. After switching to vendored mode, that build fails, and it fails for every package rather than just the patched one. Nothing warns about it. The only vendored warning, vendor_integrity_unverified, is about Pipenv not checking the hash at install time. Meanwhile docs/testing/pipenv-compatibility.md:79 lists pipenv requirements as supported ("it exports the hosted URL / vendored path").

I didn't find a lock shape that avoids this. Appending #sha256=<hex> to the relative file path (as hosted does for its URL) makes pipenv sync fail and pip reject the line as a nonexistent path. So the fix is probably a documented limitation plus a warning, for example in the vendored Pipenv warnings or the takeover output, pointing at hosted mode or plain pipenv requirements without --hash. A real export fix would be better if one exists.

Repro (Linux, Pipenv 2026.8.0, py3.12)

mkdir proj && cd proj
cat > Pipfile <<'EOF'
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
six = "==1.16.0"
idna = "==3.7"
EOF
PIPENV_VENV_IN_PROJECT=1 pipenv install && rm -rf .venv
socket-patch scan --json --yes --vendor --vendor-source service --cwd .   # six has a patch; exit 0
pipenv requirements --hash > /tmp/req.txt
#   idna==3.7; … --hash=sha256:028f… --hash=sha256:82fe…
#   ./.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl ; python_version >= '2.7' …   (no hash)
python3.12 -m venv /tmp/pv && /tmp/pv/bin/pip install --no-deps -r /tmp/req.txt
#   ERROR: Hashes are required in --require-hashes mode … exit 1; nothing installed

The control is the same commands with --mode=hosted instead of --vendor …: pip exits 0 and installs the patched six. I ran it against a local mock patch API that serves a patched copy of the real six-1.16.0 wheel, the same shape as crates/socket-patch-cli/tests/vex_pipenv_pip_real.

Expected vs actual

• Expected: a vendored Pipfile.lock stays usable through Pipenv's documented export (pipenv-compatibility.md:79). If Pipenv makes that impossible, it's a documented limitation that the CLI warns about, the way vendor_integrity_unverified and pypi_pipenv_stale_install cover Pipenv's other gaps.
• Actual: exit 0 and no warning, and the next pip install -r of the exported file fails outright.

Matrix (Linux, main 9c43dfc)

Plain pipenv requirements (no --hash) works on all of these, as long as no other line carries a hash. I didn't bisect the exact 2023.x release where the hash was dropped. macOS and Windows are untested: the export logic is pure Python, so I'd expect the same result there.

Suspect location

• crates/socket-patch-core/src/vendor/pypi_pipenv.rs:144: the only vendored Pipenv advisory (vendor_integrity_unverified) doesn't mention the export gap.
• docs/testing/pipenv-compatibility.md:79 and the Pipenv cell in docs/ecosystems.md:18: they don't document it.

Backlog review — 2026-10-08

Priority: P1 → P2. Pipenv hash export breaks the pip installation explicitly; hashes are not silently bypassed.