jaraco
commented
1 year ago I like this idea!
Generally speaking, I've been trying to minimize the number of supplied backends, to focus on behavior needed by the most common platforms. I've even been considering moving those backends into their own packages and only installing them on the relevant platforms, to be replaced with a conditional dependency like keyrings.windows; sys_platform == "win32".
The fact that a test backend would only be recommended for test environments suggests that it too has narrow applicability so probably should be a third party package (such that it would only be installed when needed and could have its own features like a pytest plugin).
Regardless, if it were to become embedded in this codebase, I'd first want to see it proven in a third-party package and demonstrating value beyond one or two users.
I'd be happy to help support your authoring such a package. I'd even be willing to host it and develop the scaffolding (so you could focus on developing the implementation). Of course, you're also welcome to implement it in a fork of keyring (to illustrate and prove the approach); just be aware it's unlikely to be merged without first being vetted as a plugin.
As far as I can see, there's no backend (either in keyring, keyring.alt or PyPI) which is designed for running as a test backend to check that calls to keyring are correct. Mocks could be used, but given backends are somewhat deployment specific anyway, having a test backend would avoid every project having their own mocks.
Would such a test backend be acceptable to the main keyring codebase? Naturally it would never be used unless requested, and would be documented as not to be used for anything else than testing (e.g. would be in memory only, so would not work as a keychain), or is keychain sufficiently frozen as to require this to be a third party backend?