KeyringLocked error when trying to publish (on a system with keyring and an unrelated KDE app instaled)

[encukou]

Thank you for Flit! I finally made a package with it, and found it very easy and polished!

Except for one issue.
On my system, keyring (and so flit) defaults to using the KDE Wallet. This is not intentional: I do some KDE application installed that requires kwallet libraries, but I don't seem to have any kwallet configuration UI to go along with it, and after some cursory research I don't want to trust kwallet to save my passwords.

Running flit publish looks like this for me:

$ flit publish 
Found 17 files tracked in git                                                              I-flit.sdist
Writing generated setup.py                                                                 I-flit.sdist
Built sdist: dist/....tar.gz                                                          I-flit_core.sdist
Copying package file(s) from /tmp/tmpwwtybui_/.../....py                              I-flit_core.wheel
Writing metadata files                                                                I-flit_core.wheel
Writing the record of files                                                           I-flit_core.wheel
Built wheel: dist/...-py3-none-any.whl                                                I-flit_core.wheel
Using repository at https://upload.pypi.org/legacy/                                       I-flit.upload

(click Cancel)

Traceback (most recent call last):
  File "/usr/bin/flit", line 8, in <module>
    sys.exit(main())
  File "/usr/lib/python3.10/site-packages/flit/__init__.py", line 163, in main
    main(args.ini_file, repository, formats=set(args.format or []),
  File "/usr/lib/python3.10/site-packages/flit/upload.py", line 261, in main
    do_upload(built.wheel.file, built.wheel.builder.metadata, repo_name)
  File "/usr/lib/python3.10/site-packages/flit/upload.py", line 243, in do_upload
    repo = get_repository(repo_name)
  File "/usr/lib/python3.10/site-packages/flit/upload.py", line 121, in get_repository
    repo['password'] = get_password(repo, prefer_env=(name is None))
  File "/usr/lib/python3.10/site-packages/flit/upload.py", line 151, in get_password
    stored_pw = keyring.get_password(repo['url'], repo['username'])
  File "/usr/lib/python3.10/site-packages/keyring/core.py", line 55, in get_password
    return get_keyring().get_password(service_name, username)
  File "/usr/lib/python3.10/site-packages/keyring/backends/chainer.py", line 51, in get_password
    password = keyring.get_password(service, username)
  File "/usr/lib/python3.10/site-packages/keyring/backends/kwallet.py", line 112, in get_password
    raise KeyringLocked("Failed to unlock the keyring!")
keyring.errors.KeyringLocked: Failed to unlock the keyring!

Flit documentation mentions it uses keyring library, whose README lists many options on how to configure it from code (i.e. what Flit can do, but as a user I can't), before mentioning I can run keyring --disable or set PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring. That works for me, but the experience isn't smooth.

Perhaps Flit could handle the error more gracefully, or point to the end-user-facing keyring documentation?

It looks like this error in keyring, which best fixed in KDE (1, 2), but that's now way outside what I wanted to do with Flit. Reporting this seems like the best I can do to help with the time I have.

[pradyunsg]

I think presenting a better error message in this is definitely reasonable and a worthwhile enhancement. @takluyver do you have any preferences between making the message self-contained vs linking to the existing keyring documentation?

[takluyver]

Thanks! I agree there are probably better ways we can present this to the user. We already handle the case where keyring finds no password by falling back to an interactive prompt, so a simple option is to do the same on this error, probably along with a message saying that keyring access was denied.

It's annoying that kwallet prompts to create a keyring even when we're just looking for an existing password, but I don't think there's anything we can easily do about that. 😕

Just to mention a few possible workarounds (not least for other people getting this error and finding this issue):

• If you put your username and password (or an API token) in a ~/.pypirc file, Flit will use that in preference to keyring. Obviously putting secrets in a plain file isn't great either, but it is simple. 🤷
• Likewise, you can pass credentials in environment variables FLIT_USERNAME and FLIT_PASSWORD.
• If you're happy with the idea of letting keyring store your password/tokens but don't like kwallet, you can install Gnome keyring, or another program implementing the secret service API (e.g. Keepass XC) - keyring will prefer these if you're not in a KDE session - or you can install another keyring backend.

I've also thought about making an interface to manage your PyPI credentials as a separate program, but I don't think it's possible on the generic keyring API - there's no way to list secrets, only query for a specific one. I could probably do it on the SecretStorage API, but then it's only useful for a subset of Linux users (including me, so I may get round to this one day anyway).