You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We are looking at using cargo-deny to enforce an internal allow list of external (registry) crates, for a large project with many Rust repositories. The problem we have is that the current allow list support requires even workspace crates to be listed in the allow list.
This will not scale to our needs, given how many different workspaces there are; the single centralized allow list should cover only external (e.g. non-workspace) crates, without needing to include all internal workspace crates from all the repositories.
Describe the solution you'd like
For our purposes, we would like an option that can cause cargo deny check bans to treat all workspace crates as implicitly allowed. Something like cargo deny check bans --allow-workspace-crates would potentially work. This issue pertains specifically to allow lists since obviously one doesn't ban one's own workspace crates :-)
Describe alternatives you've considered
Another option would be to filter bans to only crates from specific sources/registries, e.g. something like cargo deny check bans --filter-source=crates.io to check the allow/ban list for only crates from crates-io. But since the core feature we're suggesting is "allow workspace crates," having the flag be workspace-related rather than source-related seems better.
Additional context
The existing --workspace argument seems not to affect the behavior of cargo deny check bans in any way (or at least, not in any way that affects this scenario).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We are looking at using cargo-deny to enforce an internal allow list of external (registry) crates, for a large project with many Rust repositories. The problem we have is that the current allow list support requires even workspace crates to be listed in the allow list.
This will not scale to our needs, given how many different workspaces there are; the single centralized allow list should cover only external (e.g. non-workspace) crates, without needing to include all internal workspace crates from all the repositories.
Describe the solution you'd like
For our purposes, we would like an option that can cause
cargo deny check bans
to treat all workspace crates as implicitly allowed. Something likecargo deny check bans --allow-workspace-crates
would potentially work. This issue pertains specifically to allow lists since obviously one doesn't ban one's own workspace crates :-)Describe alternatives you've considered
Another option would be to filter bans to only crates from specific sources/registries, e.g. something like
cargo deny check bans --filter-source=crates.io
to check the allow/ban list for only crates from crates-io. But since the core feature we're suggesting is "allow workspace crates," having the flag be workspace-related rather than source-related seems better.Additional context
The existing
--workspace
argument seems not to affect the behavior ofcargo deny check bans
in any way (or at least, not in any way that affects this scenario).The text was updated successfully, but these errors were encountered: