GeezerVison

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

Fixes #604

Summary

On a fresh checkout (no venv, the usual CI case), lock-only requirements.txt discovery built each purl from the == version as written: six==1.16 became pkg:pypi/[email protected], ==1.16.0.0 became @1.16.0.0, and ==01.16.0 became @01.16.0. pip resolves all three to the registry release 1.16.0, but the patch is keyed pkg:pypi/[email protected] and the API matches purls exactly. So scan exited 0 with "No patches available", nothing was rewritten, and pip installed the unpatched release. The same file with a venv holding six 1.16.0 was patched (the #478 rewriters already compare == under PEP 440).

Root cause

utils/requirements.rs exact_pin returns the spelled version, vendor/lock_inventory/pypi.rs builds the lock-only purl from it, and the scan sent only that spelling to /patches/batch.

Fix

• utils::pep440::equivalent_release_spellings returns the other spellings of a pure release: leading zeros dropped, and the release padded or trimmed between its trailing-zero-trimmed form and at least three segments (1.16 → 1.16.0; 1.16.0 → 1.16; 01.16.0.0 → 1.16, 1.16.0). Pre/post/dev/local versions get none.
• Two new helpers in utils::purl_key: pypi_equivalent_purls and pypi_same_release.
• scan: the batch query now carries, for each lockfile-only PyPI purl, its equivalent spellings (deduplicated by PurlKey). Installed packages aren't expanded, and scannedPackages / lockfileOnlyPackages still count packages, not queries. After the fetch, an API purl that names a lockfile-only pin under another spelling is added to the lockfile-only set, so notInstalled, the [NOT INSTALLED] marker and the vendored baseline pre-check treat it as that package. Hosted and vendored writers then match the pin under PEP 440 as before.
• docs/testing/uv-compatibility.md documents the behavior.

Trade-off: a lock-only x.y.0 pin now also asks for @x.y (a registry might publish 4.2 for a ==4.2.0 pin). That's one extra purl in the batch body per such pin.

Tests (red → green)

Red was verified by disabling the query expansion.

Commands run

• cargo test -p socket-patch-core --lib: 6110 passed
• cargo test -p socket-patch-cli --no-fail-fast (whole suite, non-ignored): every binary passes except e2e_vendor_cargo_build's two old-toolchain cases. Those fail locally only, with "Bad CPU type in executable" from an x86 rustup 1.41 toolchain on arm64, which is unrelated.
• cargo clippy --workspace --all-features -- -D warnings: clean. cargo fmt --all -- --check: my files clean (the upstream/mod.rs diff is pre-existing on main)

🤖 Generated with Claude Code