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

> 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 https://github.com/bit-team/backintime/issues/990#issuecomment-1272014311_

Start by reviewing keyring's chainer behavior and the existing get_keyring() entry point. Evaluate the proposed APIs for listing supported password safes and persisting a selected backend, including how application-specific selection should work. Done means the API design and configuration behavior are clearly specified and supported by appropriate tests.

Written by the indexing model from the issue text.