uv/crates/uv-keyring/src
konsti cd49e1d11f
Use the windows crate facade consistently (#15737)
The initial motivation for this change was that we were using both the
`windows`, the `window_sys` and the `windows_core` crate in various
places. These crates have slightly unconventional versioning scheme
where there is a large workspace with the same version in general, but
only some crates get breaking releases when a new breaking release
happens, the others stay on the previous breaking version. The `windows`
crate is a shim for all three of them, with a single version. This
simplifies handling the versions.

Using `windows` over `windows_sys` has the advantage of a higher level
error interface, we now get a `Result` for all windows API calls instead
of C-style int-returns and get-last-error calls. This makes the
uv-keyring crate more resilient.

We keep using the `windows_registry` crate, which provides a higher
level interface to windows registry access.
2025-09-09 15:07:14 +00:00
..
blocking.rs Add new uv-keyring crate that vendors the keyring-rs crate (#14725) 2025-08-15 15:57:56 +02:00
credential.rs Add new uv-keyring crate that vendors the keyring-rs crate (#14725) 2025-08-15 15:57:56 +02:00
error.rs Use thiserror for keyring error type (#15561) 2025-08-28 08:09:11 -05:00
lib.rs Remove the native system store from the keyring providers (#15612) 2025-09-02 13:16:52 -05:00
macos.rs Remove the native system store from the keyring providers (#15612) 2025-09-02 13:16:52 -05:00
mock.rs Add new uv-keyring crate that vendors the keyring-rs crate (#14725) 2025-08-15 15:57:56 +02:00
secret_service.rs Remove the native system store from the keyring providers (#15612) 2025-09-02 13:16:52 -05:00
windows.rs Use the windows crate facade consistently (#15737) 2025-09-09 15:07:14 +00:00