Review for --index <name> support

[zanieb]

Review of #17455

Addressed my comments there, as well as some edge cases I found:

1. When the uv.toml contains an index and uv add --index name was used, we would add the tool.uv.sources entry but subsequent resolutions would fail because source entries require a co-located index definition. The fix chosen here is to fail instead with a helpful error message.
2. When --index foo was used, we would fail immediately if foo was not a known index name. This regressed the existing behavior, where we'd expect foo to be a directory. The fix chosen here was to retain the existing behavior and warn that we'd require ./foo in the future.
3. When --index name was used and name referred to an index with default = true, we did not toggle the default flag and the index was still considered lowest priority. The resolution chosen here was to move the index priority by unsetting the default flag, such that it would be equivalent to --index <url>.
4. When a workspace member defined an index with a relative path, selection of that index by name would result in computing the path relative to the workspace root instead of the workspace member, breaking resolution. The fix chosen here was to compute the proper path during loading of indexes from workspace members.
5. When using --index name with a workspace member as a working directory, we would not load find indexes defined in the workspace member — we'd require --package member too. The fix chosen here was to load workspace member indexes for the working directory.

[EliteTK]

Maybe this is a good approach to handling explicit indexes too?

If you pass one to uv add it preserves whatever was set, but if you pass multiple to uv add or any to other commands, we treat them as normal indexes?

It would save all that error handling.

[zanieb]

Multiple explicit indexes?

[EliteTK]

I mean specifically passing multiple indexes where at least one of them is explicit.

[zanieb]

I think that sounds too confusing.

[EliteTK]

If manually persisting it would work, why would automatically persisting it be broken?

Alternatively, if automatically persisting it is broken, then why would manually persisting it work?

[zanieb]

This error message needs to be improved (or, we can allow it — but it's weird)

[EliteTK]

Okay, to summarise the discussion we had on this topic:

The root cause is likely that the indexes from a pyproject.toml adjacent uv.toml are marked as having the Project origin, and this is what is used to determine if the index should be written back. But, we don't read that same uv.toml to pick up tool.uv.sources indexes (one of the reason why we write back other named indexes).

To make this work, we would need to distinguish between indexes from a pyproject.toml adjacent uv.toml when persisting.

Alternatively, we don't allow index definitions from a pyproject.toml adjacent uv.toml to be picked up by name at all.

Maybe the idea here would be that a pyproject.toml adjacent uv.toml shouldn't be allowed to have indexes? I initially thought nothing could use these without --index <name> anyway but I am actually not so sure any more.

The other option is to keep this error in this place, but to word it slightly better. Although I think the heuristic could still avoid this overhead of checking the index against the existing ones manually.