Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ban a crate unless used via a wrapper #225

Closed
thomcc opened this issue Jul 14, 2020 · 2 comments · Fixed by #238
Closed

Ban a crate unless used via a wrapper #225

thomcc opened this issue Jul 14, 2020 · 2 comments · Fixed by #238
Labels
enhancement New feature or request

Comments

@thomcc
Copy link
Contributor

thomcc commented Jul 14, 2020

Is your feature request related to a problem? Please describe.

Two cases where this seems useful:

  1. 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.

  2. 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.

@Jake-Shadle
Copy link
Member

Seems reasonable!

@repi
Copy link
Contributor

repi commented Jul 14, 2020

Interesting suggestion, and yeah sounds useful!

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
3 participants