GeezerVison

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

Fixes #928

Summary

uv pip compile --universal writes one requirements line per marker branch when a package resolves to different versions on different Pythons:

six==1.16.0 ; python_full_version < '3.12'
six==1.17.0 ; python_full_version >= '3.12'

Vendored mode refused to vendor [email protected] from that file with a false pypi_requirement_not_pinned: six is not pinned to ==1.16.0. Hosted requirements and vendored pylock already handle the same split. With this PR, vendored requirements rewrite only the 1.16.0 branch, keeping its marker and hash mode, and leave the 1.17.0 branch alone. Revert is byte-identical.

Root cause

In crates/socket-patch-core/src/vendor/pypi_requirements.rs, scan_pins set found_range for every same-name requirement that wasn't an exact pin of the target version, whatever its marker. find_pin then ranks Range above Exact ("a file that names the package ambiguously is never rewritten"). But the marker separates the two lines, so pip installs exactly one of them and nothing is ambiguous.

Fix

• utils::pep440::is_exact_pin(spec): a new helper that recognises an == pin of any valid release. It has the same shape as is_exact_pin_of, without the version comparison.
• scan_pins: an exact pin of another version that carries a marker counts as a disjoint branch, not a range, as long as at least one target pin exists and every target pin carries a marker too.
• These cases stay fail-closed and are still refused as Range:
  • the other version is unmarked
  • any target pin is unmarked
  • the other branch is a range, === or a wildcard
  • the file has no target pin, because appending an unmarked vendor line would clash with the other branch
• The rewrite and revert code paths are unchanged. They already rewrite every exact target span and carry its marker.
• CI port: ec03260 carries Route Gradle digests through utils::digest #878's digest-helper fix, because main's CI is red on utils::digest::tests::production_digests_go_through_the_helpers. It becomes a no-op once Route Gradle digests through utils::digest #878 lands.

Dry-run note: after this fix, the issue's --dry-run repro previews would_vendor and the real run vendors, so the two agree again. The vendored preview still runs only the npm, Bun and vlt preflights, not the requirements one. That gap is by design (see the preview_vendor_json doc comment) and is not part of this root cause.

Test evidence

Commands run locally:

• cargo clippy --workspace --all-features -- -D warnings: clean, with the Route Gradle digests through utils::digest #878 port included.
• cargo fmt --all -- --check: the touched files are clean. main itself isn't rustfmt-clean, and CI doesn't run fmt, so I reverted the unrelated reformatting fmt produced.
• cargo test -p socket-patch-core --all-features --lib with the Route Gradle digests through utils::digest #878 port: 5248 passed, 4 failed. All 4 also fail on main (9c43dfc) in this sandbox. They're permission tests that can't fail a write when run as root: copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_… and pypi_requirements::wire_failure_rolls_back_…. CI runs as a normal user.
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_pypi_build -- pip_vendored_requirements_marker_split pip_vendored_requirements_evaluate_environment_markers: 2 passed.
• A full cargo test --workspace can't link in this sandbox because the disk fills up, so CI covers the rest.

No wrapper changes are needed: the npm, pypi and gem wrappers only dispatch to the binary.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CTNUJ6piYReSsL98PS26Ue

Generated by Claude Code