You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use a Google Artifact Registry (GAR) repository as a proxy for the public PyPi repository. We have noticed that adding/updating packages is much slower using the GAR proxy than public PyPi. Inspecting the logging from pdm update -v reveals PDM seems to be redownloading packages when resolving while this does not happen using public PyPi.
Note that GAR does a redirect when fetching the HTML with packages versions. For example, https://<REGION>-python.pkg.dev/<PROJECT>/<REPO>/simple/ruff/ redirects to https://<REGION>-python.pkg.dev/artifacts-downloads/namespaces/<PROJECT>/repositories/<REPO>/downloads/<RANDOM_STRING> with some random string at the end of the URL. Might this be interfering with the caching PDM does?
Are you willing to submit a PR to fix this bug?
Yes, I would like to submit a PR.
The text was updated successfully, but these errors were encountered:
Describe the bug
We use a Google Artifact Registry (GAR) repository as a proxy for the public PyPi repository. We have noticed that adding/updating packages is much slower using the GAR proxy than public PyPi. Inspecting the logging from
pdm update -v
reveals PDM seems to be redownloading packages when resolving while this does not happen using public PyPi.Example of such download (full logging below):
To reproduce
Minimal pyproject.toml:
Expected Behavior
PDM should not redownload (cached) packages
Environment Information
pdm -v output
Running
pdm update -v --no-sync ruff
With public PyPy:
With GAR PyPi proxy:
Additional Context
Note that GAR does a redirect when fetching the HTML with packages versions. For example,
https://<REGION>-python.pkg.dev/<PROJECT>/<REPO>/simple/ruff/
redirects tohttps://<REGION>-python.pkg.dev/artifacts-downloads/namespaces/<PROJECT>/repositories/<REPO>/downloads/<RANDOM_STRING>
with some random string at the end of the URL. Might this be interfering with the caching PDM does?Are you willing to submit a PR to fix this bug?
The text was updated successfully, but these errors were encountered: