search

EmbarkStudios / krates

📦 Creates graphs of crates from cargo metadata 🦀
Apache License 2.0
58 stars 17 forks source link

Document the status of resolver v2 support #91

Open Shnatsel opened 3 months ago

Shnatsel commented 3 months ago

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 the resolve graph produced by cargo 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 or cargo 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!

Shnatsel commented 3 months ago

I have a minimal reproducing example for the effects of not having resolver v2 support in this branch, if it helps: https://github.com/rust-secure-code/cargo-auditable/compare/master...fix-resolver-v2 The added tests are currently failing, since the tool uses the bare cargo metadata.

Jake-Shadle commented 3 months ago

krates only ever creates a single graph, if you need to have a split between build and runtime you'd need to create 2 graphs, using https://docs.rs/krates/latest/krates/struct.Builder.html#method.ignore_kind to filter out the crates/features that you don't want in each one.

Shnatsel commented 3 months ago

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.