Let devpi fall back to other options if keyring fails - #582
Conversation
keyring provides a plugin to supply the password to devpi-client. However, if keyring fails - e.g. it's installed but no backend is working, or unlocking the keyring fails - then `devpi login` becomes impossible, because the keyring exception is uncaught. This catches any KeyringError, and returns None instead, which signals to devpi that it should try another way to get the password ([docs](https://devpi.net/docs/devpi/devpi/stable/+d/devguide/hooks.html#devpi-client-plugin-hooks-experimental)).
|
LGTM. I'd prefer to use the suppress decorator, but I'll use your change as inspiration. |
|
In this latest patch, I add the use of the jaraco.context.suppress as a simple, elegant decorator. Unfortunately, because that behavior isn't in the stdlib, it adds a dependency, which I just can't justify for an entry point like this, so I'll find another way. |
|
Hello, I tested with Python 3.8 and 3.9 (same behavior). Looks like a backwards-compatibility decision in A suggestion for |
keyring provides a plugin to supply the password to devpi-client. However, if keyring fails - e.g. it's installed but no backend is working, or unlocking the keyring fails - then
devpi loginbecomes impossible, because the keyring exception is uncaught.This catches any KeyringError, and returns None instead, which signals to devpi that it should try another way to get the password (docs).