non-target-specific / unconditional dependencies on potentially unusable credential providers

[decathorpe]

I see that different credentials providers were recently merged: #12334
Is there a reason why the dependencies for the various credentials providers are unconditional? This is kind of awkward, especially for Linux distributions, where we package the "cargo" crate (for example, as a dependency of "cargo-c"), and cannot package macOS- and Windows-specific crates like windows-sys or security-framework.

I would have thought that the libsecret provider could be specific to Linux/BSD, the macOS keychain provider specific to ... well, macOS, and the wincred provider specific to windows targets. Right cargo pulls in all of them unconditionally - should they be optional and / or target-scoped?

PS: The published crates for the new cargo-credentials* crates also don't contain the required MIT / Apache-2.0 license files. I can submit a PR for that, if it helps.

[epage]

Unconditionally depending on the platform credential providers provides a trivial way to fallback when the platform is unsupported. It can be worked around but I'm not seeing a case for why to bother. Those credential providers make the platform-specific dependencies, like windows-sys, conditional on the platform. Whether cargo does it or cargo-credential-wincred`, it would effectively be the same.

[cuviper]

Whether cargo does it or cargo-credential-wincred`, it would effectively be the same.

For packaging crates as Fedora does, doing it in cargo means skipping those crates entirely that are useless on that platform, so those packages don't need to be created at all.

[cuviper]

I'm willing to try a patch to shuffle that arrangement, if you're not totally opposed.

[epage]

I see no harm in what we are doing (yes, 3 more packages to package but the dependency tree is large enough that that is noise).

So for myself, that is what I would be weighing any refactor against and would be a high bar to achieve.

[cuviper]

It's not a big change to filter this -- #12949.