Should third party keyring backends use keyringrc.cfg, or use their own config file?

[jfly]

I'm using the keyrings.codeartifact backend, which expects its configuration to be stored in keyring's keyringrc.cfg file:

• Code: https://github.com/jmkeyes/keyrings.codeartifact/blob/1.2.0/keyrings/codeartifact.py#L30
• Documentation: https://github.com/jmkeyes/keyrings.codeartifact/tree/1.2.0?tab=readme-ov-file#config

Is this supported? Or should keyrings.codeartifact look for its own config file? Reusing the config file feels a little odd to me, as there's potential for naming conflicts, but maybe that's unlikely if folks are reasonable about naming.

If this is supported, then I think keyring is overly strict in how it parses its config file:

• If the config file doesn't exist, then it silently does nothing. Great.
• If the config file does exist, but there isn't a backend.default-keyring setting, then it raises configparser.NoOptionError, which gets logged as a "Keyring config file contains incorrect values" warning.

I can work around this by explicitly setting the backend.default-keyring setting, but I'd rather not set a configuration option that I don't have to just to avoid a warning.

[jaraco]

To my recollection, it hasn't been explicitly supported or not supported. I suspect other backends like keyrings.alt re-use the same platform module for configuration, so I'm not surprised that other backends are using it. I'm inclined to say it should be supported.

And I agree with your assessment - adding unrelated config shouldn't break the behavior compared to an empty config.

Are you willing/interested to work on a fix?