How to disable keyring

[mbukatov]

Twine supports keyring, but it's not clear to me how to use twine without this support. Is this implemented or do we just miss documentation?

[jaraco]

Code is here. You have a few options.

1. Don't have keyring installed in your environment.
2. Don't have a password defined in the preferred keyring for the relevant URL and username.
3. Have a keyring configured that causes an error retrieving the password (will emit a warning with twine but still prompt).

In that scenario, it will prompt for a password.

[brainwane]

Let's find someplace to add this to the documentation.

[mbukatov]

I stumbled upon this again, but now I don't recall how information from #338 (comment) helped me, as I don't have an option to uninstall neither kwallet (I still would like to have some kde tools installed, even when I don't use it as desktop) nor python-keyring package (because that would try to uninstall twine as well).

[mbukatov]

When I delete the kwalled database file and run twine again, I get window asking for setting up new wallet, and when I cancel it, twine still doesn't ask for a password:

$ twine upload dist/*
Uploading distributions to https://upload.pypi.org/legacy/
KeyringLocked: Failed to unlock the keyring!
$ rpm -q twine
twine-1.9.1-5.fc28.noarch

[brainwane]

@jaraco any tips?

[jaraco]

cannot uninstall python-keyring package (because that would try to uninstall twine as well).

Well, that's annoying. In the Python ecosystem, this isn't a problem because keyring is an optional, "extra" dependency on twine. My intention was that only users that planned to use keyring and have it configured would actually be interested in installing it to their environment. It sounds like you have a system package manager that doesn't have that nuance and unconditionally requires keyring.

So it does seem that perhaps this project or keyring should provide some way to disable keyring even when it's present and viable.

And then I have to wonder - should the Python ecosystem assume the same, and make keyring an unconditional dependency of twine, and rely on the additional functionality to suppress the use of keyring for environments where it's not wanted?

[jaraco]

I figured it out.

Have a keyring configured that causes an error retrieving the password (will emit a warning with twine but still prompt).

Here's how to do it:

$ mkdir -p $(python -c 'import keyring.util.platform_; print(keyring.util.platform_.config_root())')
$ echo '[backend]\ndefault-keyring=keyring.backends.fail.Keyring' > $(python -c 'import keyring.util.platform_; print(keyring.util.platform_.config_root())')/keyringrc.cfg

Test that it's working with keyring get system user, which should emit something like:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/keyring", line 11, in <module>
    sys.exit(main())
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/keyring/cli.py", line 120, in main
    return cli.run(argv)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/keyring/cli.py", line 62, in run
    password = get_password(service, username)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/keyring/core.py", line 41, in get_password
    return _keyring_backend.get_password(service_name, username)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/keyring/backends/fail.py", line 23, in get_password
    raise RuntimeError(msg)
RuntimeError: No recommended backend was available. Install the keyrings.alt package if you want to use the non-recommended backends. See README.rst for details.

[jaraco]

Keyring 15.1.0 provides an easier way to achieve what you're after, either through a command-line option that configures the environment or an environment variable you can set. See the above referenced issue for details.

Note, if you don't have keyring 15.1.0 in your main environment, you can still download keyring 15.1.0 to invoke the configuration behavior. Here's an example using rwt:

# don't do this
rwt -q keyring==15.1.0 -- -m keyring --disable

I just realized the above recommendation to disable keyring on earlier versions wouldn't work at all... because under the hood, it's configuring a keyring that only exists on this latest release.

So the best recommendation I have for older versions of keyring is in the previous comment.

[jaraco]

Thinking about the lingering documentation issue, I'm kinda torn. The best recommendation, to use keyring --disable, isn't all that helpful unless you have the latest keyring. Maybe it makes sense to link in the documentation to this issue until keyring 15.1 has been out for some time and at that point just put that recommendation inline in the docs?