GeezerVison

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

Fixes #564

Summary

uv ignores every [tool.uv.sources] entry when no-sources = true is set, and (uv 0.10+) the entries of the packages listed in no-sources-package. Hosted scan and vendor both wired the patch through such an entry anyway and reported success. Locked installs (uv sync --locked, uv lock --check) then failed, and a plain uv sync installed the unpatched registry wheel.

Both modes now refuse before writing anything:

Root cause

Both writers that add [tool.uv.sources] never read uv's no-sources setting:

• hosted: utils/python_script.rs rewrite_sources, reached from plan_python_metadata_with in patch/redirect
• vendored: vendor/pypi_uv.rs (projects) and vendor/pypi_lock.rs (script locks)

The fix adds one shared check, python_script::refuse_uv_no_sources, which all three call. It follows uv's precedence. I checked each rule against real uv 0.11.32 with uv lock --offline and a local path source:

• A PEP 723 script's own [tool.uv] wins.
• Otherwise a project uv.toml replaces pyproject's [tool.uv] settings completely. If a uv.toml exists without the key, a pyproject no-sources = true is ignored.
• A script without its own setting takes the project's setting (uv.toml, else pyproject [tool.uv]).
• no-sources-package lists from a script and the project combine; an explicit no-sources = false disables the list; names compare normalized.

Hosted mode now reads uv.toml as advisory input beside a uv lock (hosted/engine.rs). It is never written. A symlinked or unreadable one is left out instead of refusing the run, the same as the other read-only inputs.

Tests (red → green)

Before the fix, each new test failed on main. All pass with it.

• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 hosted project, pyproject [tool.uv] and uv.toml variants, plus precedence: patch::redirect::python_metadata_pairing_tests::no_sources_refuses_a_source_uv_would_ignore
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 hosted script, its own [tool.uv], uv.toml, and the pyproject fallback: same test
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 vendored project, pyproject and uv.toml variants: vendor::pypi_uv::tests::guards_refuse_workspace_lock_version_fork_sources_and_dynamic
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 vendored script lock, script, uv.toml and pyproject variants, nothing written: vendor::pypi_lock::tests::script_no_sources_refuses_before_writing
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 no-sources-package (review): normalized name, uv.toml, other packages, script+project merge, no-sources = false: the hosted and both vendored tests above
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 end to end through the CLI, both modes and both config files, tree byte-identical afterwards: mode_migration_pypi::uv_no_sources_is_refused_in_both_modes

Local checks

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: everything passes except 13 tests that also fail in this sandbox for unrelated reasons. 12 depend on chmod denying writes, which root bypasses; 4 of those were re-run as nobody and pass. 1 (e2e_bun_lockb) needs the real patch API, which this sandbox can't reach. None of them touch uv.
• The real-uv e2e suites (e2e_redirect_uv_build, e2e_vendor_pypi_build) need PyPI and were not run locally; CI covers them. No wrapper (npm/, pypi/, gem/) changes are needed: they only dispatch to the binary.

Review notes (/code-review high)

Fixed: script fallback to pyproject [tool.uv]; uv.toml read as advisory (a strict registry read would have refused unrelated hosted runs); an unparseable or unreadable uv.toml no longer surfaces as a no-sources or lock-parse error; the vendored script check reads the config once per run.

Not changed:

• Parent-directory uv.toml. Not reproducible for wired projects. uv stops its settings lookup at a pyproject that has a [tool.uv] table, and the [tool.uv.sources] entry the wiring adds is one. Checked with uv 0.11.32.
• User-level uv.toml, UV_NO_SOURCES, --no-sources. These belong to the installing machine, not the project, so the scan can't see them. This is documented in docs/testing/uv-compatibility.md.
• An already-vendored in-sync project that later gets no-sources = true now fails with pypi_uv_no_sources instead of reporting InSync. That matches the existing load-time guards (dynamic deps, workspaces). Such a project is not actually patched under uv, so failing loudly is the intent. vendor --revert doesn't go through this loader and still works.
• Hosted re-checks per patched dep (a few TOML parses), the same as the neighbouring guards. Not worth a cache.

🤖 Generated with Claude Code

https://claude.ai/code/session_014C6hY72T6RCtYwyGvxAmoT

Generated by Claude Code