Pip install block waiting forever for a keyring to unlock #7883
Comments
triage-new-issues
bot
added
the
S: needs triage
|
having the same issue here, can't understand why keyring is needed on |
Instruct pip to not use a keyring by setting an environment variable (PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring). As far as I know, there is no need to use a keyring for any of the pip commands autospec runs. Some users have encountered timeouts similar to the report from pypa/pip#7883, which describes this environment variable setting as a workaround. Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Instruct pip to not use a keyring by setting an environment variable (PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring). As far as I know, there is no need to use a keyring for any of the pip commands autospec runs. Some users have encountered timeouts similar to the report from pypa/pip#7883, which describes this environment variable setting as a workaround. Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
|
Any solution to this? I have the same issue after a reboot on Ubuntu 18.04 |
Not a solution, but I as a workaround have added the following to my |
|
I just got this on Debian Testing, gnome. This doesn't happen with a fresh environment, though. Just one with poetry installed. (Probably the addition of the non-default keyring package.) |
|
I am also experiencing pip hanging indefinitely on getting credentials from the keyring when using |
|
I'm also having this on ArchLinux under i3; I reported it at #9391 before being pointed here (thanks for correcting me!). I have screenshots:
Plus, it particularly gets in the way if I'm working on a real tty (e.g. Ctrl-Alt-F3) instead of an GUI terminal emulator. There, pip hangs but doesn't prompt because the prompt is open under X11 and I don't see it -- and pip can't proceed -- until I switch (Ctrl-Alt-F7) and cancel it there. |
|
And I second being very
|
|
In case it helps someone, I have a different workaround than #7883 (comment), which also avoids other apps, like Chrome, from nagging me in the same way: my problem stems from Arch packaging lightdm (and gdm, lxdm, and ssdm) with gnome-keyring built in: which is why logging in via lightdm causes it to spawn: and pip to print that prompt and leave this "WARNING: keyring ..": Once I found this, getting rid of it was easy: --- /etc/pam.d/lightdm.orig 2020-12-31 21:19:10.151609312 -0500
+++ /etc/pam.d/lightdm 2020-12-31 21:12:17.601523586 -0500
@@ -1,7 +1,7 @@
#%PAM-1.0
auth include system-login
--auth optional pam_gnome_keyring.so
+#-auth optional pam_gnome_keyring.so
account include system-login
password include system-login
session include system-login
--session optional pam_gnome_keyring.so auto_start
+#-session optional pam_gnome_keyring.so auto_startthat plus rebooting successfully disabled pip bothering me: |
|
Getting hassled for a password just to install a package when no password is needed was annoying, but thankfully only required a few stabs of the Today, it starts blocking indefinitely, waiting for something, and when I hit The problem has been known of for more than a year (see issue #6773), why is this this crazy behaviour the default? |
|
Is there anyone who could explain why was this odd behavior introduced? Or link to a document explaining it? It's really annoying to know that a tool so core to the ecosystem can be messed up this way this easily. |
|
Same here, Debian-Testing + KDE. It is really strange (MS Windows style) behaviour, especially from pipenv. Keyring reports "Some application requires..." instead of "pip requires...". The modal dialog causes that everything hangs, it has 2 options (Cancel/Open). With Cancel the dialog repeats immediatelly. Please prevent this. |
|
I'm getting this too and it's very disconcerting |
|
Add me to the list that has wasted HOURS tracking this down. Thanks for the workaround |
|
My workaround in #7883 (comment) has stopped working. But gnome-keyring is back: Chromium is not triggering the gnome-keyring prompt like it was before -- which is why I tried to disable it completely instead of only solving it for people. But now the only thing I've found so far that triggers it is pip. I have these: I've switched to @JohnVillalovos's solution (#7883 (comment)) and that seems to be working for me. |
|
Well, I'll add one to the mix for you all. Pip3 fails to do anything even after minutes and I need to keyboardinterrupt it. I ended up doing what any man with not enough time for this would do: I monkey patched keyring on my local system:
Result: Pip is blazing again and I can move on with my life. |
|
I had the problem on WSL2 that |
This was it for me. I was doing some display forwarding over an X server to run Qemu using WSL and forgot I had display set, but did not have the display server running! |
Had the same issue. After starting my xserver, it worked on WSL2. |
|
I ended up just removing the I'm not sure if twine will work without |
Happened to me: a number of days ago I had to workaround a pip issuehttps://github.com/pypa/pip/issues/7883 for which Q&D workaround was just to export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring . Then I lived happily ever after (since 1-May?), probably even datalad download-url was just reusing prior cookies etc. But while troubleshooting earthdata data access, I was at WTF stage that datalad kept asking for credentials, and there were no visual feedback on a reason.
|
#8687 indeed fixes this for 99.9% of cases (i.e. only prompts the keyring when there’s a 401 Unauthorized), so make sure to have pip updated to ≥ 21.1 if you’re running into this issue. |
Environment
jaraco/keyring: v20.0.1 (automatically installed as PIP dependency)
Description
Pip block during install, waiting for a keyring to unlock (at least that's my understanding)
Expected behavior
Pip install should proceed.
I'm also confused about why pypi try to use any keyring to access pypi.org (See in the verbose output
Getting credentials from keyring for https://pypi.org/simple).How to Reproduce
pip install -vvv --no-deps --no-cache-dir -U importlib-metadata==1.1.3
Workaround
Disable the keyring
Likely related issue: #6773
Output
The text was updated successfully, but these errors were encountered: