GeezerVison

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

Fixes #1587

Summary

pip installs a requirements.txt line such as wheels/six-1.16.0-py3-none-any.whl, six-1.16.0-py3-none-any.whl or dist/six-1.16.0.tar.gz as a local, unpatched artifact. Before this fix, vex ignored those lines and attested not_affected for a Socket wiring of the same release in Pipfile.lock. Only the ./wheels/… spelling was withheld (#1562). These spellings now contest the wiring the same way, so vex withholds the statement with patched_ref_unattributable.

Root cause

requirement_location (crates/socket-patch-core/src/vex/discover/pypi_other.rs) read a line as a path only when its first character wasn't a letter or digit. pip's rule (_looks_like_path / _get_url_from_path) is different: a token is a path when it holds a path separator, starts with ., or names an archive file.

Changes

• utils::requirements, the shared requirements grammar, gets pip's rule as pip_reads_as_path, with is_archive_file (pip's ARCHIVE_EXTENSIONS, and its splitext handling of .tar.<ext>), names_before_at and strip_path_extras.
• requirement_location uses these helpers and now also follows pip on two more points:
  • A no-space six@https://… or six@wheels/…whl is a PEP 508 reference to six. Before, the url form was read as a bare url and lost its declared name.
  • A path's [extras] are cut before its filename is read, so wheels/six-…whl[socks] also contests.

Tests (red → green)

The red runs used main's pypi_other.rs with the new e2e cases in place.

Local runs:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib: 6536 passed, 4 failed. The 4 are chmod-based tests that can't fail under uid 0 in this sandbox: relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, and the poetry and requirements write-failure tests. Other agent PRs report the same 4 on main.
• e2e_vex_lockfile: 350 passed
• e2e_vex_redirect (53), e2e_vex_vendor (52), in_process_redirect_pipenv (11), in_process_vendor_pypi_takeover (6), scan_requirements_lock_only (10) and scan_vendor_requirements_unwired (4): all pass
• npm/pypi/gem wrappers: not touched, since they only dispatch the binary

CI and Bugbot

Merge queue (2026-10-20): dequeued on the pipenv pylock leg, a main-wide break from uv 0.13.2+ (also fails main nightly, #1605, #1614). Ported #1639's uv 0.13.1 pin in 29877b3 after merging main; CI green there, pipenv leg included.

CI on 3a4de37: ci-ok green, no failed checks. Bugbot reviewed 3a4de37 and found no issues.

/code-review high

Fixed in 3a4de37:

• six@https://… lost its declared name.
• [extras] on a path hid its filename.
• The archive test didn't split .tar.<ext> the way pip does.
• The rule lived privately in VEX discovery. It now sits in the shared requirements grammar.

Not changed:

• Rare archive suffixes pip accepts (.tar, .tbz, .txz, .tlz, .tar.lz, .tar.lzma) are now read as paths. The release can't be read from those filenames, though, so they still give no evidence, as before this PR. Real sdists use .tar.gz or .zip (PEP 625 requires .tar.gz). Widening the filename reader would also change the hosted rewriter and the lock inventory.
• Hosted/vendored requirements writers: requirement_name still reads a bare path line as a name (wheels). These writers don't attest anything. Whether they should treat such a line as an install source of the package is a separate change, left as a follow-up.

https://claude.ai/code/session_01JM7idHTBGCQp9fzoGJviT3

Generated by Claude Code