Open jfly opened 2 months ago
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?
I'm using the
keyrings.codeartifact
backend, which expects its configuration to be stored in keyring'skeyringrc.cfg
file: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:
backend.default-keyring
setting, then it raisesconfigparser.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.