-
Notifications
You must be signed in to change notification settings - Fork 17
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
Document the status of resolver v2 support #91
Comments
I have a minimal reproducing example for the effects of not having resolver v2 support in this branch, if it helps: rust-secure-code/cargo-auditable@master...fix-resolver-v2 |
|
I've done some initial tests and it does appear to be supported. Here's an example showing it in action: https://github.com/Shnatsel/krates/blob/9b813f753393dc46053b2852a751f0777918dc57/examples/resolver_v2.rs I'm not confident that I got the difference between resolver v1 and v2 exactly right in my tests, so there may be something I'm missing. But the initial results are promising. |
Cargo has made it possible to depend on the same version of a given crate with different feature sets, provided that one version is a runtime dependency and another is a build dependency.
cargo metadata
somewhat notoriously is not aware of that, which leads it to conflate the build-only Cargo features with runtime features. While in reality there are two dependency graphs,cargo metadata
still treats them as one. This causes theresolve
graph produced bycargo metadata
to include features and dependencies that aren't actually included in the build.This is problematic for tools that need the precise dependency graph, such as
cargo auditable
orcargo cyclonedx
.It would be great to know whether
krates
overcomes this limitation, and have some example code for querying both graphs (runtime and build dependencies). It it does, then it is a big step forward for those tools!The text was updated successfully, but these errors were encountered: