GeezerVison

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

Fixes #964

Summary

A vendored scan of a fresh uv checkout (uv.lock, no .venv synced yet), or of a directory holding only PEP 723 script locks, no longer pulls the system Python's packages into the candidate set. Before this, every OS-Python package with a Socket patch (PyYAML, requests, … on stock Ubuntu runners) made scan --mode vendored exit 1 with pypi_uv_lock_package_missing, even when nothing the project depends on was patched.

Root cause

PythonCrawler::get_site_packages_paths falls back to get_global_python_site_packages() whenever the cwd has a Python project marker but no project env was found. A uv project only ever installs into uv's own env (./.venv or UV_PROJECT_ENVIRONMENT), and a script lock's env lives in uv's cache. So with nothing synced yet, nothing is installed for the project, and its lock-only packages already come from the lock (lockfileOnlyPackages).

Same root cause as #947 / #504. PR #950 handles the Pipenv half with an is_pipenv_project guard at the same spot; this PR adds the uv half. The two touch adjacent lines, so whichever lands second needs a trivial merge.

Change

• uv_owns_project_env(cwd) is true for a uv.lock that no other manager shares, or a directory whose only Python markers are *.py.lock script locks. In that case the crawl returns no env instead of falling back.
• A uv.lock next to Poetry / PDM / Pipenv files keeps the old fallback, because Poetry with virtualenvs.create = false installs into the interpreter it runs on. The "another manager claims this project" check moved out of uv_project_environment_site_packages into claimed_by_non_uv_manager, so both share it.
• Removed get_site_packages_paths_falls_back_via_uv_lock_marker, which pinned the buggy behaviour. CLI_CONTRACT's "cwd-only" section already describes the new behaviour.
• The pypi_uv_lock_package_missing remedy text in vendor/pypi_uv.rs is unchanged. Without the fallback, a package the project doesn't depend on can't reach it any more.
• Ported CI fix: 064b21d is Route Gradle digests through utils::digest #878's change (Gradle digests go through utils::digest). main is red on production_digests_go_through_the_helpers, and the change no-ops once Route Gradle digests through utils::digest #878 lands.
• 1822d82 reverts a cargo fmt --all sweep that had reformatted 118 files this fix doesn't touch. Each reverted file is byte-identical to rustfmt's output on the merge-base version. The diff is now the 6 files listed in the PR.

Tests (red → green)

Local runs

• cargo clippy --workspace --all-features -- -D warnings ✅ (re-run on 1822d82)
• crawler_python_e2e (62) and in_process_python_envs (20) ✅ (re-run on 1822d82)
• cargo test -p socket-patch-core --all-features: all pass except 4 lib tests that inject failures with chmod (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…). They can't fail as uid 0, which is how this container runs, and they pass in CI.
• CLI: in_process_python_envs, e2e_pypi, hosted_superseding_pypi, mode_migration_pypi ✅. covgap_commands_vendor: 3 tests that inject state-write failures fail for the same root reason.
• e2e_vendor_pypi_build -- --include-ignored (uv 0.11.32): 35/35 ✅
• e2e_redirect_uv_build -- --ignored: 5 ✅. 4 fail because the test binary can't reach https://pypi.org/pypi/six/1.16.0/json through this sandbox's TLS proxy during the upstream restore step, which this diff doesn't touch. CI runs these with real network.
• The full cargo test --workspace can't link within this session's disk allowance, so CI is the full-suite gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_012H7zqyRTeMzzAxit6xfV6r