More precise dependency list #210
Conversation
…ode with the cargo-tree command
| fn parse_cargo_tree_line(line: &str) -> CargoTreePkg { | ||
| let parts: Vec<&str> = line.split_ascii_whitespace().collect(); | ||
| let name = parts[0].to_owned(); | ||
| let version_str = parts[1]; | ||
| let version_str = version_str | ||
| .strip_prefix("v") | ||
| .expect("Failed to parse version string \"{version_str}\": does not start with 'v'"); | ||
| // Technically this can fail because crates.io didn't always enforce semver validity, and crates with invalid semver exist. | ||
| // But since we're relying on the cargo_metadata crate that also parses semver, in those cases we're screwed regardless. | ||
| let version = cargo_metadata::semver::Version::parse(version_str).unwrap(); | ||
| CargoTreePkg { name, version } |
There was a problem hiding this comment.
To better prepare for a LTS Linux distribution having an old cargo-auditable (which is mentioned in another fn docstring in this PR), it might be worthwhile adding a few ways to avoid problems if cargo tree .. output changes in a way that could break cargo-auditable .
- Don't use
cargo treefor binaries that are not in a workspace, as I assume that is the only time whencargo treeis beneficial. - Have a command line flag or envvar flag to turn off using
cargo tree. - This function and its callers ripple up any parsing errors (including
parts[1]) in aResult, and have a command line flag or envvar flag to allow the user to choose whether to fail or emit warnings when this parser fails.
2 & 3 could be the same config item, likeCARGO_AUDITABLE_USE_CARGO_TREE=off,on,warn
I personally dont mind if these protections are not done. Just ideas to help get this feature across the line.
There was a problem hiding this comment.
It actually helps with more than just workspaces. cargo metadata also does somewhat incorrect platform resolution, e.g. with rustix depending on errno on Linux according to cargo metadata but not cargo tree unless you use cargo tree --platforms=all, so it needs to be enabled unconditionally.
cargo metadata's feature unification across all dependency types, including dev-dependencies, causes it to over-report the dependency graph in certain cases. This PR works around that, fixing the long-standing issue #66