uv: Failed to install a package from a public url on 0.1.33

since yesterday, we are experimented this issue

 > [worker  7/13] RUN uv pip install --system --no-cache -r /tmp/shipping/reqs/requirements-dev.txt:
0.416 error: Failed to download: pyrovider @ https://github.com/Shiphero/pyrovider/releases/download/1.2.4/pyrovider-1.2.4-py3-none-any.whl
0.416   Caused by: HTTP status client error (401 Unauthorized) for url (https://objects.githubusercontent.com/github-production-release-asset-2e65be/144867083/d56d51b0-fe2d-4eda-a5f2-8f9d6503ce92?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240418%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240418T144100Z&X-Amz-Expires=300&X-Amz-Signature=6b628fe5fc427071d8bc8bc84688ecda750075f74d01e4fc236ee4a1cc9eb9af&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=144867083&response-content-disposition=attachment%3B%20filename%3Dpyrovider-1.2.4-py3-none-any.whl&response-content-type=application%2Foctet-stream)

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?

About this issue

Original URL
State: closed
Created 2 months ago
Comments: 17 (8 by maintainers)

Commits related to this issue

Restore seeding of authentication cache from index URLs (#3124) Roughly reverts https://github.com/astral-sh/uv/pull/2976/commits/f7820ceaa7a24613ce89da77c48a0454c1e94616 to reduce possible race co... — committed to astral-sh/uv by zanieb 2 months ago
Fix authentication for URLs with a shared realm (#3130) 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 ... — committed to astral-sh/uv by zanieb 2 months ago

Most upvoted comments

I think there are two things going on here:

We fixed our caching to actually apply per network location as intended in the original implementation, but this means we can apply credentials to requests that don’t need it.
We stopped pre-seeding the cache with the URLs passed via the CLI, I think this is causing some sort of race condition where we don’t apply credentials to some in flight requests because they’re not cached yet.

zanieb on Apr 18, 2024