-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Huge slowdown when using keyring(google artifact registry) in 0.1.34/35 and auth problem in 0.1.36 #3205
Comments
Thanks for the issue! We made a bunch of changes to authentication in #2976 and #3130 to ensure correctness but these come with some performance cost. Regardless it shouldn't be this slow, I'll investigate that. Sorry to see it works in v0.1.35 and doesn't in v0.1.36, can you provide |
I am seeing a similar issue with Azure artifacts. Installation worked with 0.1.35 but has broken in 0.1.36. As far as I can see the keyring is never accessed and only unauthorized requests are attempted. |
I've put up a fix at #3206. Will investigate the performance problems separately. |
Fixes the failure to lookup credentials in #3205 The issue is that we seed the cache with the index URL which includes a username but no password. We did not ensure that a password was present in the cached credentials before attempting a request with them. Now, the cache will not return credentials when a username is provided and the cached credentials have no password — the cached credentials are useless in that case. Tested with a Google Artifact Registry and keyring ``` RUST_LOG=uv=trace cargo run -q -- pip install requests --index-url https://oauth2accesstoken@us-central1-python.pkg.dev/<project>/pypi/simple/ --no-cache --keyring-provider subprocess -v ```
@zanieb do you still need logs? If so, for which version Also, I have done
|
@avelychko12 thanks for the logs. I believe all this should be addressed by #3206. I'll release that now. |
So, I tried 0.1.37 and problem from 0.1.36 is gone, thx. |
Thanks I'm looking into improving performance further. |
Unfortunately the previous implementation had some correctness issues so we may not reach that level of performance with the keyring subprocess. |
One way to improve performance is to allow custom keyring command. Already now one could probably just substitute |
Closes #3205 Tested with `RUST_LOG=uv=trace cargo run -- pip install -r scripts/requirements/trio.in --index-url https://oauth2accesstoken@us-central1-python.pkg.dev/zb-test-project-421213/pypyi/simple/ --no-cache --keyring-provider subprocess -vv --reinstall 2>&1 | grep keyring` On `main` you can see a dozen keyring attempts at once. Here, the other requests wait for the first attempt and only a single keyring call is performed.
0.1.38 works as fast as 0.1.33 (If you already have the latest versions installed, at least) |
I have a virtualenv where I already have
requests
installed from default pypi, and if I don't use any extra index url then everything is fine, with extra index url with token everything is fine as wellbut with keyring it's like x3 slower than in 0.1.33
and it doesn't work with 0.1.36
keyring version:
keyring==25.1.0 keyrings-google-artifactregistry-auth==1.1.2
The text was updated successfully, but these errors were encountered: