Dev only features aren't pruned #60
Labels
bug
Something isn't working
Comments
Jake-Shadle
changed the title
Jake-Shadle
added a commit
that referenced
this issue
Jan 12, 2024
Previously the graph was built by going from each root package to each of its dependencies recursively until all packages that were referenced were visited. This mostly worked fine, however had issues, namely #60, that were caused by there being tension between our view of the graph and cargo metadata's. `cargo metadata` presents a "complete" view of a graph, however if a user requested only packages for specific platforms or only of specific kinds, we were still including features that `cargo metadata` had resolved with its complete view of the graph, even if those features were only enabled by an edge that was otherwise pruned. So now, we just does our own resolution by recursively walking each package + feature combination rooted at the features enabled on each root crate which allows us to accurately prune nodes as we go rather than doing complicated fixup passes or the like
Merged
Jake-Shadle
added a commit
that referenced
this issue
Jan 12, 2024
* Oops * Add test for #60 * Refactor graph building Previously the graph was built by going from each root package to each of its dependencies recursively until all packages that were referenced were visited. This mostly worked fine, however had issues, namely #60, that were caused by there being tension between our view of the graph and cargo metadata's. `cargo metadata` presents a "complete" view of a graph, however if a user requested only packages for specific platforms or only of specific kinds, we were still including features that `cargo metadata` had resolved with its complete view of the graph, even if those features were only enabled by an edge that was otherwise pruned. So now, we just does our own resolution by recursively walking each package + feature combination rooted at the features enabled on each root crate which allows us to accurately prune nodes as we go rather than doing complicated fixup passes or the like * Update * Fix lint * Don't use path deps * Normalize paths
|
Thanks for the quick fix for this issue. I confirmed it works with |
Tastaturtaste
added a commit
to Tastaturtaste/argmin
that referenced
this issue
Jan 14, 2024
…mbarkStudios/krates#60 is available in the cargo-deny-action
stefan-k
pushed a commit
to argmin-rs/argmin
that referenced
this issue
Jan 14, 2024
…mbarkStudios/krates#60 is available in the cargo-deny-action
Jake-Shadle
added a commit
to EmbarkStudios/cargo-deny
that referenced
this issue
Jan 19, 2024
This fixes 2 bugs that were originally opened on this repo but really belong to the crate used to create crate graphs: - EmbarkStudios/krates#60 - EmbarkStudios/krates#64 Resolves: #584
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A comment in another issue describing the differing behaviour with context
In the PR linked above, I use
cargo tree -i intel-mkl-src --all-features -e "no-dev,features"to see if there is a non-dev-dependency onintel-mkl-src, which has a license I don't want to introduce.resolver = "1"in the workspaceintel-mkl-srcis present due to feature unification with a dev-dependencyresolver = "2"in the workspace it is not present anymore (which is what I want)However
cargo deny --log-level error --all-features --exclude-dev check licensesstill complains aboutintel-mkl-srcregardless of the usedresolver. I would expectcargo-denyto use the same resolver cargo itself uses.To reproduce
resolver = "2"in the workspaceCargo.tomlcargo tree -i intel-mkl-src --all-features -e "no-dev,features"cargo deny --log-level error --all-features --exclude-dev check licensescargo-deny version
cargo-deny 0.14.3
What OS were you running cargo-deny on?
Windows
Additional context
If you need any more context or information please let me know.
The text was updated successfully, but these errors were encountered: