poetry: Error: Unable to store the password for poetry-repository-pypi in the key ring: Failed to unlock the collection!

OK keyringerror again. Then fixed it by keyring --disable in terminal on Ubuntu. Then poetry publish --build as usual OK!

I have a Mac, and I needed to delete an old password in the Keychain in order to get it to work. I went to the Keychain Access app, navigated to the login default keychain and filtered on Passwords. In there was one called poetry-repositor-***, where *** was my private repo. Deleting that and running poetry config http-basic.<PRIVATE-REPO> <USER> <TOKEN> again solved this issue for me.

Had the same problem in a container, solved it by setting the null keyring within the underlying lib, it’s just an env variable:

PYTHON_KEYRING_BACKEND: keyring.backends.null.Keyring

see https://pypi.org/project/keyring/ disabling keyring

this fixed it for me… https://blog.frank-mich.com/python-poetry-1-0-0-private-repo-issue-fix/

Poetry strikes again 💣

Why does poetry need the keyring? Is it possible to build/deploy in CI/CD without using a keyring?

I’m running into a similar error with Poetry v1.2.0 for simple operations like installing a plugin in my Debian development environment. I’m not sure whether this is exactly the same issue as described above or just results in a similar error message.

$ poetry self add poetry-dynamic-versioning-plugin
Failed to unlock the collection!

This seems to have happened because I was SSH’d into my development environment, which has the GNOME Keyring installed. When I RDP’d in so I would have an X session, then the GNOME keyring dialog popped up to unlock the keyring. On the surface, it doesn’t seem like there’s any need for the keyring in this situation, because I’m installing a public plugin. It seems like maybe there’s a code path where Poetry attempts to unlock the keyring even if it’s not going to be needed.

I don’t get this error on Windows or MacOS, although it’s possible that a keyring is just silently being unlocked under the covers on those platforms, and I don’t notice because it’s not failing.

My workaround is to explicitly set a null keyring as suggested in @Cardu 's comment above, in Poetry issue #6277, and also in pip issue #6773:

$ PYTHON_KEYRING_BACKEND="keyring.backends.null.Keyring" poetry self add poetry-dynamic-versioning-plugin

I also confirmed that keyring --disable works as in @KafCoppelia 's suggestion. However, I don’t like that solution for my use case, because it permanently disables the keyring in configuration, and I do need the keyring available for other things.

sudo pacman -S gnome-keyring

This, but is not cool to have to install something of gnome if you are not using gnome…

well, maybe a permission problem, with “sudo” save me in this case

Had the same problem in a container, solved it by setting the null keyring within the underlying lib, it’s just an env variable:

PYTHON_KEYRING_BACKEND: keyring.backends.null.Keyring

see https://pypi.org/project/keyring/ disabling keyring

This, easiest solution and worked perfectly

Just to add to the macos solutions above: the Issue for me was that the key is added to the keychain with access only allowed by a specific python version. When I switched python versions then the poetry config command started failing. The solution is to allow all apps on the poetry keys or add the additional python versions you need. Ideally poetry would handle this or at least provide a better error message.

Also happens to me when connecting via SSH, and my workaround is to disable keyring within a sufficient scope, as poetry can work without keyring.

My two cents are that this behaviour is not consistent with the docs. The documentation promises a backup in case of keyring failure:

If a system keyring is available and supported, the password is stored to and retrieved from the keyring... 
If access to keyring fails or is unsupported, this will **fall back to writing the password to the auth.toml** file along with the username.

Of course, it may well be an issue on the keyring side (locked, not set up properly…), but would be nice to fall back gracefully. A bit odd, but sometimes poetry depends on keyring even for password-free operations in config:

(.venv) azureuser@sense-mskorski:~/projects/test_project$ poetry config virtualenvs.create false


  KeyRingError

  Unable to retrieve the password for poetry-repository-my_private_repo from the key ring

EDIT: the keyring usage is handled in poetry.utils.password_manager and has improved a bit since in version 1.2, in particular with respect to null backends.

https://github.com/python-poetry/poetry/blob/0686427ce175e14b69c8ffeca4515cce79453047/src/poetry/utils/password_manager.py#L109-L141

@earonesty poetry uses keyring for storing credentials. It is entirely possible to build/deploy in CI/CD without any issues.

right, but why bother storing credentials? i don’t want it to.

• tried setting POETRY_PYPI_TOKEN_PYPI to a valid token… didn’t help… still wants my keyring
• seems like it should try reading from ~/.pypirc like twine does…
• poetry config and its sundry ways could be mentioned in the error messages?
• tried the config - was “unable to unlock the collection” & how to turn off keyring support, so it will fall back?
• messed with dbus env vars… poetry decided to store stuff plain text… which worked! but when i log in again, it goes back to failing to use the keyring unless i kill my dbus settings again
• sticking it on the command line works, but then i have to worry about my bash log

@earonesty poetry uses keyring for storing credentials. It is entirely possible to build/deploy in CI/CD without any issues.

https://github.com/python-poetry/poetry/blob/17b165bf8c8d989d672417fd4610721df59ae1d0/.github/workflows/release.yml#L261-L266

Why does poetry need the keyring? Is it possible to build/deploy in CI/CD without using a keyring?

I’m quite curious about this as well actually.

https://github.com/python-poetry/poetry/issues/2692#issuecomment-996489094

I can’t remember ever having to install any package with root permissions. Infact, If I remember correctly, pip specifically warns against it.

Also, why exactly does poetry modify the error Traceback?

sigh I have other questions, but mainly why does poetry even request access from the keyring in the first place?

sudo pacman -S gnome-keyring solved it for me.

Oh fixed it today by using poetry config http-basic.pypi username password.

Similar error occured when I was using poetry build then poetry publish to publish my python project to PYPI.🤔 But yesterday before the problem ocurred Poetry did in normal.

KeyRingError

Unable to retrieve the password for poetry-repository-pypi from the key ring

at ~/.local/share/pypoetry/venv/lib/python3.8/site-packages/poetry/utils/password_manager.py:39 in get_password 35│ 36│ try: 37│ return keyring.get_password(name, username) 38│ except (RuntimeError, keyring.errors.KeyringError): → 39│ raise KeyRingError( 40│ “Unable to retrieve the password for {} from the key ring”.format(name) 41│ ) 42│ 43│ def set_password(self, name, username, password):