New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 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).