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.

Update: #8623 (comment) suggests that poetry config keyring.enabled false is a more permanent workaround.

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

[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)

[Youjin1985]

Still an issue on Ubuntu 22.04 and poetry 1.8.3. Please fix, I spend a lot of time to found this thread.

[4ydan]

I encountered this problem on the latest raspian too.

[Popkornium18]

Poetry can't fix a broken keyring setup. Either fix the keyring or disable the use of the keyring in the poetry config.

[alanwilter]

@Popkornium18 The point is that poetry doesn’t provide any hints about where the issue might be, which can leave people feeling lost. In reality, the issue is often quite simple — once you know where to look. Many users aren’t familiar with keyring or even aware of what it is.

As discussed before, what if poetry could check for keyring and give a warning message?

[Popkornium18]

Poetry does provide hints in verbose modes. It states that it is trying to access the keyring and then it hangs.

The keyring access is part of a library that poetry uses. There is no simple way to test if an available keyring is broken. If it is broken the call to the library code just simply hangs an never returns to the poetry code that might try to handle it.

[henryk]

Just ran into it again (my last time was ~6 months ago) on a fresh raspberry pi.

Is there a way to limit the keyring initialization to just cases where poetry actually, you know, needs keyring access? To me it seems like a 5% case. In my 20 or so projects with poetry (most of them professionally) I have had to access a private repo exactly once. And even then we were using restricted deploy tokens which don't need a secrets manager.

[codethief]

@henryk

Is there a way to limit the keyring initialization to just cases where poetry actually, you know, needs keyring access?

Not that I know of but there is #8761 at least!

[andrewpollock]

We've just freshly migrated to Poetry from Pipenv and this isn't a very delightful first user experience...

[andrewpollock]

@ilyagr would you mind editing the workaround statement to mention poetry config keyring.enabled false? That seems like the more correct and durable workaround.

[rod7760]

Why would keyring.enabled true be a sane default? Improve security practices?

[radoering]

Why would keyring.enabled true be a sane default? Improve security practices?

Two reasons:

1. Before the setting was introduced, keyring support had always been enabled. Thus, making true the default did not result in a behavior change.
2. Security by default.

Considering how many users have issues with keyring, maybe, we should consider changing the default to false in Poetry 2.0? Although, disabling a security setting by default feels bad...

[andrewpollock]

Considering how many users have issues with keyring, maybe, we should consider changing the default to false in Poetry 2.0? Although, disabling a security setting by default feels bad...

In terms of UX, even emitting a line alerting the user to this potential for an indefinite hang (and the solution) would go a long way. Even better if the conditions are detectable, and the warning is contingent on them? Then you could explore conditionally falling back to a false setting

[codethief]

Adding to what @andrewpollock said, one could also add a prompt before "unlock keyring", warning the user and allowing them to choose between unlocking the keyring and skipping it. Though, I would argue the very first thing to do would be fixing #8761 as this might already solve a good 80% of all issues.

[alanwilter]

I got another similar problem: somehow, in hindsight, my ssh-agent was down and poetry update was taking forever. With poetry update -vvv I could see that I had a prompt asking for my passphrase!
I really wish poetry could do better in these cases.

[acochrane]

I also experience this issue with brand new poetry install with
curl -sSL https://install.python-poetry.org | python3 -

[ivhacks]

I believe I'm experiencing this also. Fresh venvs and poetry install via pipx. Originally I was trying to work from an existing poetry.lock file, and I got this traceback when I cancelled it (for those Googling this):

Exception ignored in: <module 'threading' from '/usr/lib/python3.12/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.12/threading.py", line 1592, in _shutdown
    atexit_call()
  File "/usr/lib/python3.12/concurrent/futures/thread.py", line 31, in _python_exit
    t.join()
  File "/usr/lib/python3.12/threading.py", line 1147, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.12/threading.py", line 1167, in _wait_for_tstate_lock
    if lock.acquire(block, timeout):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I deleted poetry.lock and then it hung on Resolving dependencies.

Since I was logged in via SSH, I used the low-tech workaround of running down to the basement and doing it directly on the machine I was SSHed into.

[alexanderswerdlow]

Also experiencing this....a little unexpected given the promise of "dependency management made easy." Perhaps a simple fix could be to print a warning [regardless of mode] the first time the keyring is accessed after install?