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.
Two cases where this seems useful:
Crate X has easy-to-misuse parts of it's API so we'd like to ban it except when used through a specific wrapper we allow.
Crate X has problematic default features that are okay if they're disabled, but it's very easy to fail to disable them, so we have a crate X-wrap in our workspace that configures it properly. All use of crate X should be through this. (This is a bit of a hack but I've definitely done this without cargo deny)
Describe the solution you'd like
(Note: I don't believe skip or skip-tree are applicable, since they're about versions, which isn't what I'm concerned about. Sorry if I'm wrong and it can be made to work)
Here's a hypothetical syntax: I'm not tied to at all it just gets the point across. Maybe you could specify versions in there -- I don't have strong feelings about the naming of these fields / use of the "wrapping" metaphor.
[[bans.allow-if-wrapped]]
name = "X"wrapper = "X-wrap"
Concretely, this would if a path exists from any of the roots of the crate graph to X that does not pass a crate that's allowed via X-wrap (or another crate marked as an allow-if-wrapped.wrapper for X). If such a path exists, X would be denied. Of course, if X-wrap is a root of the crate graph, it is allowed.
Describe alternatives you've considered
For the features scenario, you could imagine incorporating features into the banning conceptual model, however it wouldn't solve the first use case mentioned. Note that the fact that one can use this to ban features does not at all prevent solving that problem more directly in the future, and does not make the two solutions redundant.
I've done sort of checking with hacky scripts before but it was not very robust.
The text was updated successfully, but these errors were encountered:
For example we have crates where we only want to allow our safeish (WIP) physx crate, but that currently uses our low-level system bindings physx-sys. But once physx gets more extensive support we want to only allow using that in our crates, but of course still allow physx to use physx-sys itself.
Is your feature request related to a problem? Please describe.
Two cases where this seems useful:
Crate X has easy-to-misuse parts of it's API so we'd like to ban it except when used through a specific wrapper we allow.
Crate X has problematic default features that are okay if they're disabled, but it's very easy to fail to disable them, so we have a crate X-wrap in our workspace that configures it properly. All use of crate X should be through this. (This is a bit of a hack but I've definitely done this without cargo deny)
Describe the solution you'd like
(Note: I don't believe
skip
orskip-tree
are applicable, since they're about versions, which isn't what I'm concerned about. Sorry if I'm wrong and it can be made to work)Here's a hypothetical syntax: I'm not tied to at all it just gets the point across. Maybe you could specify versions in there -- I don't have strong feelings about the naming of these fields / use of the "wrapping" metaphor.
Concretely, this would if a path exists from any of the roots of the crate graph to
X
that does not pass a crate that's allowed viaX-wrap
(or another crate marked as anallow-if-wrapped.wrapper
for X). If such a path exists, X would be denied. Of course, ifX-wrap
is a root of the crate graph, it is allowed.Describe alternatives you've considered
For the features scenario, you could imagine incorporating features into the banning conceptual model, however it wouldn't solve the first use case mentioned. Note that the fact that one can use this to ban features does not at all prevent solving that problem more directly in the future, and does not make the two solutions redundant.
I've done sort of checking with hacky scripts before but it was not very robust.
The text was updated successfully, but these errors were encountered: