GeezerVison

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

Fixes #412
Fixes #523

Summary

A pip project with no venv yet (a fresh clone, a CI job or a Docker build) is discovered through the lockfile-only requirements.txt inventory. That inventory missed two common ways of writing pins, so those packages never reached the patch API. scan printed "No patches available" and exited 0 in both hosted and vendored mode, and pip install -r requirements.txt then installed the unpatched release. With this PR, discovery reads the same pins pip installs.

Root cause

inventory_requirements_txt in vendor/lock_inventory/pypi.rs read requirements differently from both pip and socket-patch's own writers:

• Lockfile-only scan ignores pins in requirements.txt -r includes, so a fresh checkout reports "No patches available" and installs unpatched (hosted and vendored) #412: it read only the root requirements.txt and skipped -r lines without following them. The vendored writer, by contrast, already walks every in-root include.
• Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523: it recognized pins with utils::requirements::exact_pin, which only looked at the first whitespace token. So six == 1.15.0, six ==1.15.0, six== 1.15.0, six[x] == 1.15.0 and the legacy six (==1.15.0) weren't seen as pins. pip and the hosted rewriter (requirement_version) both accept all of these.

Changes

• utils::requirements::exact_pin now parses the requirement the way pip does: name, then optional extras, optional parentheses and ==, with whitespace allowed between them. Only options (--hash=…) may follow the version. As a side effect, a range like six==1.0,<2 is no longer mistaken for the pin 1.0,<2. Lock-only vex discovery (vex::discover::pypi_other) uses the same function and gets the fix too.
• vendor::pypi_requirements::requirements_includes is the include parser pulled out of the vendored writer's walk, now shared. is_in_root_rel is now pub(crate).
• inventory_requirements_txt reads the root file plus every in-root -r / --requirement include through a new requirements_tree walk. The walk runs over the ProjectView, so the in-memory hosted engine reads the same tree. It resolves each include relative to the including file, guards against cycles, never follows -c constraints, and skips out-of-root or absolute includes, matching the writer. The public_index rule (an index option makes hashed pins unverifiable) now spans the whole tree, because pip applies options from any file globally.

In hosted mode, an installed pin that lives only in an include is documented as rewrite-refused (redirect_requirements_entry_not_found). Lock-only checkouts now reach that same documented path instead of silently skipping the package.

Tests (red → green)

Validation

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: 214 targets. 12 tests fail only because this sandbox runs as root, which ignores the read-only or unremovable fixtures they rely on (*_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root). All 12 pass when re-run as a non-root user. Everything else passes.
• cargo test -p socket-patch-cli --test e2e_vex_build -- pip:: --ignored (real pip, every major, hosted + vendored → manifest-less VEX): ok.
• cargo fmt --all -- --check is not clean on main itself with the pinned 1.93.1 toolchain (128 files), and CI doesn't run it. The files this PR touches are rustfmt-clean, and no unrelated files were reformatted.
• The npm, pypi and gem wrappers are unaffected: the change is entirely in the Rust core.
• CI on acb0abb: 477 success, 6 skipped (matrix templates and canary/downgrade), 0 failed. native (ubuntu-latest, 2.9.3) failed once in its PDM extras vendored lane (appliedExactlyOne). That lane reads pdm.lock and never reaches the requirements.txt inventory, and it passed on its single re-run.
• Cursor Bugbot on acb0abb: no issues found.

Follow-ups

None.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JASDoVJNrZUBy9kd7fWPxN

Generated by Claude Code