Regression: Poetry 1.7 hangs instead of asking to unlock keyring

[ilyagr]

• Poetry version: 1.7.0

• Python version: 3.11.6

• OS version and name: Debian trixie (testing) running in a Chrome OS Linux container

• pyproject.toml: https://gist.github.com/ilyagr/1bebabebc93e6662d139009d19ed8c1b/edit (includes poetry.lock and detailed command-line output as well).

• I am on the latest stable Poetry version, installed using a recommended method.

• I have searched the issues of this repo and believe that this is not a duplicate.

• I have consulted the FAQ and blog for any relevant entries or release notes.

• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

This is a follow-up to #1917 and #8227. I also mentioned this briefly in
#1917 (comment)

The bug happens when I run either poetry install or poetry lock.

• Poetry 1.6.1 behavior: a Gnome (gnome-keyring or seahorse, I'm unsure) window opens and asks to unlock a keyring. If I click cancel (refuse to unlock the keyring), poetry fails with an exception as described in fix: remove exception when keyring is locked #8227.

• Current Poetry 1.7 behavior: no Gnome window opens, poetry just freezes for a while.

  With Poetry 1.7, I also tried rebooting. After a reboot, a Gnome window does appear. After clicking cancel (refuse to unlock the keyring), it reappears. After clicking cancel ~10 more times, it stops reappearing and hangs again.

rm -r ~/.cache/pypoetry as suggested in #1917 (comment) did not help, with or without reinstalling poetry (via pipx, in my case)

Expected behavior

poetry does not try to unlock the keyring unless it is performing an operation that can't succeed without access to the keyring (e.g., already failed without access to the keyring).

Alternatively, a somewhat inferior option would be to have some way to tell poetry not to try unlocking any keyrings that is easier to discover than the workaround below. Additionally, there would be a user-friendly message suggesting that option whenever unlocking the keyrings doesn't work.

Workaround

The workaround of export PYTHON_KEYRING_BACKEND=keyring.backends.fail.Keyring from #1917 (comment) still works.

Command-line output

See https://gist.github.com/ilyagr/1bebabebc93e6662d139009d19ed8c1b for details.

The end of it is often the following printed to stderr:

[keyring.backend] Loading SecretService
[keyring.backend] Loading Windows
[keyring.backend] Loading chainer
[keyring.backend] Loading libsecret
[keyring.backend] Loading macOS

At this point, it hangs forever.

[n00bsys0p]

Confirming I'm getting exactly the same behaviour on an Ubuntu dev container with no X server. Both the following workarounds worked for me, but aren't ideal. I do have private repositories in my pyproject.toml, and have configured & tested working access via Github PAT stored in ~/.git-credentials.

• export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring
• pyenv shell system followed by python3 -m keyring --disable

[bipindr123]

thank you for the workaround, it worked

[FloHu]

I have the exact same issue on Ubuntu 20.04.6 LTS and poetry version 1.7.1.

[kangqiwang]

Thanks @n00bsys0p

use Ubuntu 20, got same issue. it works

Cheers

[gmagannaDevelop]

I am running Poetry v1.7.1 / Poetry-Core v1.8.1 on Debian 12 (bookworm) x86_64. I mainly use my computer in text mode and I confirm that poetry hangs when performing an install.

When adding -vvv, it is effectively stuck in unlocking a keyring.

[kangqiwang]

I am running Poetry v1.7.1 / Poetry-Core v1.8.1 on Debian 12 (bookworm) x86_64. I mainly use my computer in text mode and I confirm that poetry hangs when performing an install.

When adding -vvv, it is effectively stuck in unlocking a keyring.

have you try ? it works for me

export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring

[ahollmann]

Same issue on Debian 12.

[Popkornium18]

If you're fine with running a prerelease version of poetry you could use this setting to disable the keyring completely.

Edit: No need for running a prerelease version, it is part of the 1.8 release.

[DbCrWk]

Same issue on Ubuntu 22.04 and Poetry 1.8.2. The workaround from @n00bsys0p worked great for me! (I only used the first one and did not test the second one.)

[namoshizun]

The workaround works. I wonder what is the root cause and whether there will be future Poetry versions addressing this issue 🤔

[damtharvey]

I ran into this today on Ubuntu 22.04. I think poetry might be trying to get the keyring through a GUI, which a lot of us don't have installed.

[alanwilter]

It should warn rather than spinning forever. I'm in a headless system, like many. Still an issue with v1.8.2

[n00bsys0p]

I found this Poetry setting, which seems likely to be the official way of disabling the keyring, but I haven't had a chance to try it yet.

[damtharvey]

Nice! Seems like it works. To clarify, you can change it with
poetry config keyring.enabled false

[alanwilter]

Good to know. The default should be False, just my 2 cents.

[agrajagco]

oh my, yes this is key, i was trying to troubleshoot a server based install and wondering if a keyring prompt was being expected to pop up where this was hanging (debian12). Thanks for the poetry config example to disable this @damtharvey and @n00bsys0p

[ryanovas]

Just experienced this myself. Updating poetry and setting the config option to false seems to have worked for me, but there really should be some kind of warning or something instead of hanging forever unless you know to check the extra extra verbose logs...

[Popkornium18]

some kind of warning or something instead of hanging forever unless you know to check the extra extra verbose logs...

I think that's fine. When an ssh command hangs the user is also expected to check the verbose output to see what is wrong. IMO the assumption that there is a working keyring is fine. Most users probably do not care about the keyring at all, so printing checking keyring for everyone would just add noise to the output for most people. Trying to detect a hanging keyring call from within poetry seems overkill to me.

Making the keyring opt-in would solve this issue, but also leave most people less secure since most people will not enable it. I would probably prefer to leave it opt-out. This is a rare issue that is rather easy to analyze and the fix is trivial (setting keyring.enabled false).

[StefanDenn3r]

I am new to poetry and was facing the exact same issue. It took me quite some time to figure out what is going wrong because I didn't know how long I was supposed to wait or how long checking the keyring would take. The verbose logs therefore only helped for checking where I might be stuck but not that I was actually stuck.

Workaround fixed it.

[matt-forallepsilon]

+1

[ilyagr]

Looking at bugs like jaraco/keyring#496, it might help if somebody ran keyring --list-backends and tried to debug what causes the issue to happen. Can it be reproduced with the "Command-line utility" described in https://pypi.org/project/keyring/? If so, it's likely a problem in the library and should be reported there.

I no longer have a computer on which this problem occurs, so I cannot do it unless I find a config where it happens.

[jeanlego]

ssh'd on a headless server got the same issue

it might help if somebody ran keyring --list-backends

hope this helps

❯ keyring --list-backends
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.libsecret.Keyring (priority: 4.8)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyring.backends.SecretService.Keyring (priority: 5)