cargo-outdated icon indicating copy to clipboard operation
cargo-outdated copied to clipboard

Provide mechanism for only scanning current target's dependencies

Open jonhoo opened this issue 2 years ago • 0 comments

cargo-outdated currently forcibly enables all targets when it resolves the workspace's dependencies: https://github.com/kbknapp/cargo-outdated/blob/fe97a089185162ffb84b91e6ce24eabf96784b62/src/cargo_ops/elaborate_workspace.rs#L90

This means that cargo-outdated will download dependencies that aren't needed for cargo build and friends, causing unnecessary network traffic, and potentially requiring network access when cargo build would not. Most Cargo tools default to only taking the current host platform into account unless another target is specifically given, but given cargo-outdated's use-case, it may make sense to instead follow the pattern of cargo metadata, which takes a --filter-platform argument to limit the search only to the given target platform when passed.

Beyond being slightly inconvenient, the lack of this particular feature is also a hurdle in strictly managed Rust build settings where the entirety of crates.io is not necessarily available, such as due to licensing constraints. As an example, imagine my crate has a dependency on some crate foo, which in turn has a target.cfg(windows).dependencies on the LGPL-3.0-licensed rug crate. Due to its license, rug is not available in my build environment. But I'm not building for Windows, so do not need rug at all, and so everything is fine! Except if I try to run cargo-outdated, because it tries to fetch dependencies for all targets, which includes the (unused) rug dependency.

As an addendum, I was surprised that cargo-outdated decides to download transitive dependencies even when -R flag is passed. In fact, it's weird to me that it needs to download dependencies at all. It stems from the call to cargo::get_many here: https://github.com/kbknapp/cargo-outdated/blob/fe97a089185162ffb84b91e6ce24eabf96784b62/src/cargo_ops/elaborate_workspace.rs#L98

Which doesn't feel like it's actually necessary — isn't the information in the index alone sufficient? Specifically, I wonder if you could just use PackageSet::packages the way cargo metadata does instead, and still have all the information you need? https://github.com/rust-lang/cargo/blob/58a961314437258065e23cb6316dfc121d96fb71/src/cargo/ops/cargo_output_metadata.rs#L136

That would almost certainly remove the need to add --filter-platform, since you wouldn't be downloading anything.

jonhoo avatar Sep 28 '21 18:09 jonhoo