tweak the order of index priority

[BurntSushi]

Previously, uv would always prioritize the index given by
--index-url. It would then try any indexes after that given by zero
or more --extra-index-url flags. This differed from pip in that any
priority was given at all, where pip doesn't guarantee any priority
ordering of indexes.

We could go in the direction of mimicing pip's behavior here, but it
at present has issues with dependency confusion attacks where packages
may get installed from indexes you don't control. More specifically,
there is an issue of different trust levels. See discussion in #171 and
PEP-0708 for more on the security impact.

In contrast, uv will only select versions for a package from a single
index. That is, even if foo is in indexes a and b, it will
only consider the versions from the index that it checks first. This
probably helps with respect to dependency confusion attacks, but also
means that uv doesn't quite cover all of the same use cases as pip.

In this PR, we retain the notion of prioritizing indexes, but
tweak it so that PyPI is preferred last as opposed to first. Or
more precisely, the --index-url flag specifies a fallback index,
not the primary index, and is deprioritized beneath every index
specified by --extra-index-url. The ordering among indexes given by
--extra-index-url remains the same: earlier indexes are prioritized
over later indexes.

While this tweak likely won't hit all use cases, I believe it will
resolve some of the most common pain points without exacerbating
dependency confusion problems.

Ref #171, Fixes #1377, Fixes #1451, Fixes #1600

[zanieb]

I believe this helps with dependency confusion attacks. If I'm providing an extra index URL that's usually the index that I control. The attack would be that someone uploads a package with the same name to the primary index (i.e. PyPI) and suddenly we use that package instead of the one I intend to.

[jarshwah]

If I'm providing an extra index URL that's usually the index that I control

As a counter-point (not suggesting this is the most common) - we use extra-index-url to install a vendor library (we pay them for access), and the index is horribly slow.

[adrienball]

I just ran into an issue which is caused by this change.
My company uses a private index, and thus I have some script which is run with UV_EXTRA_INDEX_URL=<private-index-url>.
The following issue happened when uv venv --seed is run inside the aforementioned script:

#15 0.746 Creating virtualenv at: /app/.venv
#15 0.775 uv::venv::seed
#15 0.775 
#15 0.775   × Failed to install seed packages
#15 0.775   ├─▶ No solution found when resolving: pip, setuptools, wheel
#15 0.775   ├─▶ Failed to download and build: pip==20.2.4
#15 0.775   ╰─▶ Building source distributions is disabled

After digging a bit, and trying to understand why this oldpip==20.2.4 was getting installed, I found that someone uploaded an old version of pip into the private index.
I don't know if the error results from an invalid pip wheel on the private index, or some version incompatibilities, but it made me realize that as soon as someone publishes a version of a public package in our private index, then it will potentially break all libs or apps which depend on a different version of the package.

Is there any plan to mitigate this issue ?

Thanks !

[charliermarsh]

For clarity, you can always revert to the previous behavior by inverting the order:

--index-url=<private-index-url> --extra-index-url=https://pypi.org/simple

This would tell uv to look in PyPI first, and then only fall back to your index if a package doesn't exist on PyPI.

[xnox]

How does this interact with --find-links?