> The intention of keyring is that the default behavior _should_ be suitable.

[jaraco]

    > The intention of keyring is that the default behavior _should_ be suitable.

If the presence of the chainer is causing problems, it probably shouldn't be enabled by default
or at the very least should have an escape hatch (a way for a library like backintime to disable its usage).
I'd be happy to support such a thing in keyring if simply honoring chainer as "appropriate" isn't suitable.

chainer is a cool thing and my challenge is now that the keyring API and configuration should more or less be hidden to end users since it is meant for developers or customizers (it should be a black box to end users IMHO).

So I have to give the end-user of Back In Time a simply way to configure this from the Back-in-Time-app point of view (user should not need to learn internals of keyring).

keyring's chainer uses some "heuristics" that seems to work non-deterministically from the Application point-of-view since external installations or settings may influence the priority value (I still have not completely browsed the keyring code so this is still more opinion than fact based I admit).

So the end user just want's to specify and persist the used "password safe" instead of a technical backend of an App-internal library.

And until the user does specify a "password safe" the "best guess" is the chainer so the default is good IMHO.

What would be nice in keyring to improve embedding it into an CLI or GUI app:

1. Add a public method to query for supported "password safes" (internally asking all available backends)
   return a list of the "pretty-labeled" password safes and a list of responsible backend names for each password safe
   to be used internally by 2.

   This would allow to fill a GUI widget more easily.

   Open question: How to cope with the 1:n nature of password safe to backends in the GUI then.
   The end user must take a decision for a backend finally, but based on which information?

2. Add a public method to persist the chosen backend without editing a file.
   An app (as keyring client) shoudn't have to know the storage location and file format (= encapsulate this in keyring).
   Optionally this setting could be valid only for a app (could be passed as key) but I assume that the selection
   should be right for every app/client then.

3. I assume we don't need to add an API to read the config file since the active backend (dominated by an existing config file)
   can already be queried with get_keyring().

~/.config/python_keyring/keyringrc.cfg containing ... necessary to “steer” the keyring system to using the correct backend.
If honoring an environment variable or some other mechanism would help,
keyring would be interested in exploring making this use-case simpler.

I think a persistence API would be more helpful than another env var (see proposal 2).

Originally posted by @aryoda in bit-team/backintime#990 (comment)