Repository navigation
Conversation
uv add --index inside a workspace member writes the index into that member's pyproject.toml, but the resolver only ever searched indexes defined at the workspace root plus the CLI. The member's index stayed readable for named tool.uv.sources pins and credential extraction, but was never actually searched for candidates, making it an effective no-op for anything else. Extend the resolved index locations with every member's own indexes before they reach the registry client and build dispatch, so lock and sync both pick them up. Fixes astral-sh#20678
…vior Locking without credentials now correctly reaches the member's own index (that's this PR's fix) and reports the real 401, instead of silently treating the package as absent from the registry.
|
Fixed the CI failure. The pre-existing Couldn't get a full local test run working in this environment (Git's own |
uv test inventory changesThis PR changes the tests when compared with the
|
Summary
Closes #20678.
uv add --indexinside a workspace member writes the index into that member's ownpyproject.toml. But the resolver's actual index locations only ever come from the workspace root's[[tool.uv.index]]entries plus the CLI (Workspace::indexes()is documented as "the index table from the workspace pyproject.toml", root only). The member's index stays readable for two narrower things, a namedtool.uv.sourceslookup and credential extraction, but it never gets added to the set of indexes actually searched for candidates. Outside the one case the issue calls out (a single named index gets pinned viatool.uv.sources, so it happens to work through that narrower path), the member's index is a silent no-op.Fix extends the resolved
IndexLocationsindo_lockwith every workspace member's own indexes, reusingLockTarget::indexes(), which already walks root plus all members correctly for the credentials-only case. Covers bothuv lockanduv sync, since sync goes through the samedo_lockviaLockOperation.Test Plan
Read through
Workspace::indexes()and its three call sites first to find the actual root cause, then confirmed it empirically before writing any fix: in apython:3.12-slimcontainer, installed the publisheduv0.12.1, set an unreachable index as the workspace root's default and a real one only in a member'spyproject.toml, ranuv lock, and watched it request only the bogus root index and never touch the member's.Added
lock_index_workspace_member_without_source_pinnext to the existinglock_index_workspace_membertest, samepypi_proxysetup but without thetool.uv.sourcespin, so it exercises the "just search this index" path instead of the named-lookup path. Confirmed it fails without the fix (same symptom as the manual repro above) and passes with it, by stashing just the source change and rerunning.cargo check,cargo fmt, andcargo clippy --tests -D warningsall clean.