Failed to install a package from a public url on 0.1.33 #3123
Comments
|
Hi! Sorry about that, this looks like a bug. Can you provide logs with |
|
fwiw it seems to work okay on my machine |
|
my teammate @romeroyonatan just discovered that it does not happen when installing the public package alone but in conjunction with another package from an url that requires authentication. He will share an example in a moment. |
|
btw, I just realized that this misbehavior looks a lot like #3122 and is probably related to the same root cause. |
|
Hi team, I found an easy way to reproduce the issue uv pip install 'uv-3123-bug @ https://romeroyonatan:a@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl'This is the output $ uv pip install 'uv-3123-bug @ https://romeroyonatan:a@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl'
error: Failed to download: uv-3123-bug @ https://romeroyonatan:a@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl
Caused by: HTTP status client error (401 Unauthorized) for url (https://objects.githubusercontent.com/github-production-release-asset-2e65be/788539373/37fcd109-909c-4ed1-928c-2354c9a79a48?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240418%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240418T165731Z&X-Amz-Expires=300&X-Amz-Signature=01a9bf253fb9083fd65e5b37c8b366e6349ca078644a32bac2e309e7a7ea69b2&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=788539373&response-content-disposition=attachment%3B%20filename%3Duv_3123_bug-0.0.1-py3-none-any.whl&response-content-type=application%2Foctet-stream)This is the pip behavior $ pip install 'uv-3123-bug @ https://romeroyonatan:a@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl'
Collecting uv-3123-bug@ https://romeroyonatan:a@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl
Downloading https://romeroyonatan:****@github.com/romeroyonatan/uv-3123-bug/releases/download/v0.1.4/uv_3123_bug-0.0.1-py3-none-any.whl (2.7 kB)
[notice] A new release of pip is available: 23.2.1 -> 24.0
[notice] To update, run: pip install --upgrade pipI tried to reproduce the bug using a private repo, but I found that the issue happens even with public repositories with valid or invalid credentials. I suspect the credentials are cached and we use the private credentials when we shouldn't (public repositories for example) Edit: I found the auth cache https://github.com/astral-sh/uv/blob/0.1.33/crates/uv-auth/src/cache.rs#L98-L107 |
|
Thanks a bunch ya'll! Will investigate. |
|
There is a regression in 0.1.33 where user/pass combo on custom repos no longer work. It is also affecting us here. |
|
@inoa-jboliveira can you be more explicit? Providing a username and password doesn't work for a private repository anymore? This issue is for applying credentials from private repositories to public repositories. |
|
@zanieb Yes, the credentials are being ignored. I tested 0.1.31 and 0.1.32 and they work. This and UV_INDEX_URL no longer work with user/pass combo |
|
I found in the logs that the cached credentials are used when it shouldn't (public repositories) |
|
Maybe this is a slightly different issue I'm having, but they seem to be caused by the same regression on v0.1.33 |
|
I think there are two things going on here:
|
|
Hi @zanieb, I tested the changes and it works. Great job! |
|
Seems to be working on my issue as well, thank you |
|
Thanks for giving it a try! I'll get that cleaned up and try to release today. |
|
This may go out on Monday instead. |
In #2976 I made some changes that led to regressions: - We stopped tracking URLs that we had not seen credentials for in the cache - This means the cache no longer returns a value to indicate we've seen a realm before - We stopped seeding the cache with URLs - Combined with the above, this means we no longer had a list of locations that we would never attempt to fetch credentials for - We added caching of credentials found on requests - Previously the cache was only populated from the seed or credentials found in the netrc or keyring - This meant that the cache was populated for locations that we previously did not cache, i.e. GitHub artifacts(?) Unfortunately this unveiled problems with the granularity of our cache. We cache credentials per realm (roughly the hostname) but some realms have mixed authentication modes i.e. different credentials per URL or URLs that do not require credentials. Applying credentials to a URL that does not require it can lead to a failed request, as seen in #3123 where GitHub throws a 401 when receiving credentials. To resolve this, the cache is expanded to supporting caching at two levels: - URL, cached URL must be a prefix of the request URL - Realm, exact match required When we don't have URL-level credentials cached, we attempt the request without authentication first. On failure, we'll search for realm-level credentials or fetch credentials from external services. This avoids providing credentials to new URLs unless we know we need them. Closes #3123
since yesterday, we are experimented this issue
As you can see, the package is public
https://github.com/Shiphero/pyrovider/releases/download/1.2.4/pyrovider-1.2.4-py3-none-any.whl
Pinned uv to 0.1.32 worked for now, but is it related to the breaking changes introduced in the 0.1.33 releases? Do we need to upgrade something in our requirement file?
The text was updated successfully, but these errors were encountered: