Feedback for Python binding

[unkcpz]

Hi developers,

Thank you for providing such a great tool!

For one of our team's projects, we needed a cross-platform Python API to access the system keyring. While the existing keyring library is excellent, it doesn't fully meet our requirements—particularly regarding native support for macOS and Linux keyutils.

To address this, I created a wrapper using pyo3 and published the package on PyPI. You can find the repository here: https://github.com/unkcpz/keyringrs.

I'm looking forward to hearing your feedback, and I’d especially appreciate input from the original Python keyring maintainers (pinging @jaraco). While the current implementation meets our team's needs, I’m open to exploring the possibility of making it more generic for broader Python usage—or even integrating it with keyring if it makes sense.

I look forward to your thoughts!

[jaraco]

While the existing keyring library is excellent, it doesn't fully meet our requirements—particularly regarding native support for macOS and Linux keyutils.

I'd invite you to file issues with the Keyring project around what is the use-case that's unmet. I do believe Keyring has native macOS support, but maybe there's some aspect that's yet unmet. I may not have the energy to implement more enhanced support, but I very much welcome contributions.

As for Linux keyutils, anyone is able to write plugins for additional backends in keyring. The built-in Linux support in Keyring is currently based on SecretService, but if keyutils is (more) popular, it may make sense for it to be a built-in backend or enabled by default. I'm not a heavy Linux+Keyring user, so I'd need to loop in some champions/maintainers to review any such design change, but it's certainly possible.

Keyring aims to be everything to everyone. It's a CLI and library and integrated into key projects like pip and twine and other projects like jaraco.abode. It's meant to work on any platform and allow for any backend to implement any (secure) store.

The Keyring project does aim to be a pure Python library (at least the core implementation) in order to support environments that don't have access to compilers or binaries, so a native rewrite based on Rust would be problematic. Any implementation would at the very least need to provide a pure Python fallback of essential behavior.

I hope that provides some context. I welcome you to ask more specific probing questions or open issues to explore different opportunities.

[unkcpz]

@jaraco thanks for the reply!

I do believe Keyring has native macOS support, but maybe there's some aspect that's yet unmet. I may not have the energy to implement more enhanced support, but I very much welcome contributions.

macOS is supported for sure, but just because of jaraco/keyring#670.

The Keyring project does aim to be a pure Python library (at least the core implementation) in order to support environments that don't have access to compilers or binaries, so a native rewrite based on Rust would be problematic.

In my wrapper implementation, I distribute wheels for cross-platform, so no compiler is needed, and installation is fast.

The built-in Linux support in Keyring is currently based on SecretService, but if keyutils is (more) popular, it may make sense for it to be a built-in backend or enabled by default.

We had some use cases where the dbus is not available, it was the main reason that I wrap the keyring-rs would be nice to have it supported in your package. (in fact in our team, we decide to use your python keyring and my binding as fallback solution to stick with more community support and ignore the keyutils use case for the moment.)

It is great that I got feedback from you @jaraco, so I'll close this issue to not spam discussion on python binding stuff in this repo. I'll open an issue in your repo to have further discussion.

[jaraco]

The Keyring project does aim to be a pure Python library (at least the core implementation) in order to support environments that don't have access to compilers or binaries, so a native rewrite based on Rust would be problematic.

In my wrapper implementation, I distribute wheels for cross-platform, so no compiler is needed, and installation is fast.

While supplying cross-platform wheels does cover a lot of cases, there are many others where such an approach is infeasible, such as:

• projects that insist on building from source (not relying on published binaries)
• platforms not included in the binary distributions (cygwin, emerging architectures, embedded systems)
• vendored packages (there's no established mechanism to support cross platform in this scenario)

As an example, see jaraco/inflect#195, where I attempted to utilize pydantic, also built on Rust and with wide platform support, but still found it broke several use cases and made Inflect non-viable for many cases.