Fix requirements.txt writers ignoring pip hash mode (#376, #378) - #383

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

Fixes #376
Fixes #378

Summary

Hosted and vendored scans no longer break pip install -r on a requirements.txt that has no hashes. setup no longer reports success after writing a line that pip will refuse in a hash-pinned requirements.txt.

Root cause

pip's hash-checking mode is all or nothing. It turns on for the whole install as soon as any requirement carries --hash, and then every requirement, transitive dependencies included, has to be ==-pinned and hashed. None of the three requirements.txt writers checked which mode the requirements set was in:

• The hosted redirect (patch/redirect/requirements.rs) and the vendored writer (vendor/pypi_requirements.rs::vendor_line) always added --hash. In an unhashed file that switches the mode on, and pip then refuses every other line (Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376).
• setup's requirements_add (setup/pypi/edit.rs) always appended an unpinned, unhashed socket-patch[hook]. In a hashed file, pip refuses that line (setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378).

Fix

• Shared check: utils::requirements::requires_hashes. It is true when any line has a --hash option (any algorithm) or the file sets --require-hashes. Comments and URL #sha256= fragments don't count.
• Hosted (Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376): a hashed file keeps --hash on the patched line, as before. An unhashed file gets name @ <url>#sha256=<hex> instead. Checked by hand:
  • pip 24 and uv 0.8 both verify the fragment (a wrong hash fails the install);
  • the fragment does not turn on pip's hash mode for other lines;
  • it also satisfies hash mode when that mode is on;
  • VEX already reads it (integrity_of).
• Vendored (Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376): the mode is taken from the whole requirements tree (the root file plus its -r includes). A hashed tree keeps the vendor line unchanged. An unhashed tree gets the committed wheel path with no --hash, because pip can't read a fragment on a bare path. The inventory, VEX and the in-sync ledger fallback already accept a hashless vendor line.
  • Rebuild guard: when there is no ledger entry, the in-sync rebuild guard falls back to the pin on the wired line. A hashless line now still pins its wheel path (wired_pin_in returns an empty sha256 and pin_matches checks the path only). A rebuild under another filename is refused instead of leaving the line pointing at a missing file. Bugbot found this; it is fixed in fcc4fcc.
• setup (setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378): a hashed requirements.txt, or one whose in-root -r include is hashed, now gets an error result explaining hash-checking mode and is left untouched. setup --remove now works on pip's logical lines, so a hook line's \ + --hash continuation lines are removed with it (the leftover noted in setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378). The BOM is kept.
• Re-scans are no-ops: every line counts toward the mode, the writer's own lines included, so a re-scan never flips a file between the two shapes. A file that an older version already wrote with --hash into an unhashed set keeps that shape; running rollback followed by a re-scan rewrites it in the new form.

Per-issue checklist

• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376, hosted: redirect::requirements::tests::unhashed_file_pins_the_artifact_by_url_fragment_not_hash_option and hashed_file_keeps_the_hash_option. Both were red before the fix and are green after.
• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376, vendored: vendor::pypi_requirements::tests::unhashed_requirements_get_an_unhashed_vendor_line (red → green) and hashes_in_an_include_keep_the_vendor_line_hashed.
• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376, vendored rebuild guard: vendor::pypi::tests::in_sync_ledgerless_rebuild_of_unhashed_line_keeps_the_wired_path (red → green).
• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376, real pip: a new unhashed cell (six==1.16.0 + idna==3.7) in e2e_vex_build::pip. Locally on pip 24.3.1 every hosted and vendored step passes: wire, install-patched, manifest-less VEX, re-scan.
• setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378: setup::pypi::edit::tests::test_add_refuses_hash_pinned_requirements, test_add_refuses_when_an_include_is_hash_pinned and test_requirements_remove_drops_continuation_lines (all red → green). test_add_hash_pinned_file_with_hook_is_configured is the positive control.
• Shared check: utils::requirements::tests::requires_hashes_reads_pip_hash_checking_mode.

Test updates (intended behavior change)

Several existing tests expected --hash in unhashed files, which is the #376 bug itself. They now expect the unhashed forms:

• the unit tests in the hosted and vendored writers;
• the redirect fixture and the VEX discovery golden (redirect-pypi.json);
• in_process_get_hosted_ecosystems, e2e_hosted_production, e2e_vendored_production and e2e_vendor_pypi_build.

Two tests needed more than a new expected string:

• vendor_ledger_schema_e2e: the base-binary parity test now names this one intended difference. The legacy fixtures are unchanged, so the legacy-revert coverage stays.
• The pin-guard tests and the marker e2e rely on a hashed pin, so their inputs are now hash-pinned.

An earlier commit on this branch accidentally reformatted about 55 unrelated files, and e0ed1aa reverts them. main isn't rustfmt-clean and CI doesn't check formatting, so this PR leaves formatting alone. main (including #277) was merged in at a2dedc5.

Evidence

• cargo clippy --workspace --all-features -- -D warnings: clean on fcc4fcc.
• cargo test --workspace --all-features (local, sandbox runs as root): every failure is a test that needs a write, removal or permission check to fail, which root bypasses. None exercises code this PR changes.
• SOCKET_PATCH_PIP_E2E_VERSIONS=24 SOCKET_PATCH_PIP_E2E_REQUIRED=1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- pip:: --ignored: passes for all 4 cells × 2 modes (pre-merge).
• CI is green on fcc4fcc.
• Not touched: the npm, pypi and gem wrappers (they only dispatch to the binary).

Follow-ups

• setup writes socket-patch[hook] into requirements.txt, but socket-patch-hook was never published to PyPI, so pip silently installs socket-patch 3.3.0 and no .pth hook #377 (the socket-patch-hook distribution isn't on PyPI) is release-side and labelled agent:needs-human. Once that distribution is published, a hashed hook line could be written instead of refusing.

🤖 Generated with Claude Code

https://claude.ai/code/session_017aQf44e9818AbFKDYnuAHZ