`uv add keyring` breaks private index auth

[EdAyers]

Reproduction steps

uv 0.4.4 (3d75df6ab 2024-09-04)

You need a private Azure Devops repository you can point to.

1. Follow the steps given here. But make it a non-extra index-url. That is:
   • uv tool install keyring --with artifacts-keyring
   • export UV_KEYRING_PROVIDER=subprocess
   • export UV_INDEX_URL=https://VssSessionToken@pkgs.dev.azure.com/{organisation}/{project}/_packaging/{feedName}/pypi/simple/ (note this is index_url not extra_index. I want all package installs to use my index.)
2. Make a venv uv venv; source .venv/bin/activate
3. uv add keyring: installs keyring 25.3.0 via the private index.
4. Now run uv add pandas (or any package)

  × No solution found when resolving dependencies:
  ╰─▶ Because keyring was not found in the package registry and your project depends on keyring>=25.3.0, we can conclude that your project's requirements are unsatisfiable.

If I don't run uv add keyring, uv works as expected. If instead I run uv add keyring artifacts-keyring, it works as expected.

It might be possible to reproduce with an --extra-index-url too.

I'm guessing uv is using the keyring installed in the venv instead of the global one and then is failing because artifacts-keyring is not installed. Keyring is silently failing and uv fails to find the registry. I think something that would help here is uv should give a different error if the entire index is returning a 403 or 404 rather than saying that the package can't be found.

[charliermarsh]

I'm not sure what the correct behavior is here \cc @zanieb.

I think something that would help here is uv should give a different error if the entire index is returning a 403 or 404 rather than saying that the package can't be found.

Unfortunately AFAIK there is no way to differentiate between these scenarios.

[zanieb]

I'm guessing uv is using the keyring installed in the venv instead of the global one and then is failing because artifacts-keyring is not installed.

I'm not really sure what we can do about this. This sounds like the correct behavior.

[charliermarsh]

Yeah that's how I was feeling.

[EdAyers]

I guess either:

• always use the globally installed keyring when doing index auth
• if running keyring in the venv fails, fall back to running in the global tool venv
• keep existing behaviour but it must be possible to add a warning or hint at what is going wrong. Eg maybe regex the index-url to see whether it's azure, or ping the root directory url and see if it gives a 403. Or maybe it's possible to determine that the index-url's authority is expecting the artifacts-keyring package.

I originally got this because keyring was being installed implicitly by another dependency, so my developer-experience was uv stopped working in an illegible way after installing a seemingly unrelated dependency. It took me a while of fiddling with venvs etc to figure it out. Using the verbose logs of uv didn't help either.

Anyway, I'm rooting for you!