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
Describe the bug
If a crate imported by path in the same workspace is mentioned in the ban deny list, cargo check will not error. This also seems to happen transitively.
To Reproduce
Create a worspace with crateA and crateB.
Make crateA have a path dependency on crateB by doing crateB = { path = "../crateB" }
In the deny.toml of crateA, make crateB banned in the deny list.
Ask for a cargo deny check on crateA from within crateA's folder.
Expected behavior
cargo deny check should error as crateB is not allowed as a crateA dependency. Instead, checks pass.
Device:
OS: Linux
Additional context
The reason I want to deny a crate from the same workspace as a dependency is that I am making a client and a server in the same workspace so they can share a common network crate. However when the workspace will inevitably have a more intricate dependency graph, I would like to ensure I don't accidentally link server code in the client.
The text was updated successfully, but these errors were encountered:
Describe the bug
If a crate imported by path in the same workspace is mentioned in the ban deny list, cargo check will not error. This also seems to happen transitively.
To Reproduce
crateB = { path = "../crateB" }
crateA
's folder.Expected behavior
cargo deny check should error as crateB is not allowed as a crateA dependency. Instead, checks pass.
Device:
Additional context
The reason I want to deny a crate from the same workspace as a dependency is that I am making a client and a server in the same workspace so they can share a common network crate. However when the workspace will inevitably have a more intricate dependency graph, I would like to ensure I don't accidentally link server code in the client.
The text was updated successfully, but these errors were encountered: