Add the ability to restrict what crates cargo fetch downloads by target

[briansmith]

I am building the crate only for the x86-64-unknown-linux-musl target. My crate depends on several crates that have optional, target-specific dependencies on the fuchsia-zircon crate and/or the winapi crate. Since I'm targetting Linux, I will never need those crates downloaded. However, cargo fetch --locked always downloads winapi and fuchsia-zircon, presumably just in case I decide to build for targets that need them. Downloading all the crates (currently 60, for a quite small code base) takes a non-trivial amount of time, so I'd like to avoid downloading any crates that won't be used for the targets I'm intending to build for. The cargo fetch happens in a Dockerfile and the Cargo.lock very frequently changes, causing the whole Dockerfile to be built from scratch.

I propose that we add a --target or --targets flag to cargo fetch that works analogously to the same/similarly-named flag for cargo build. In particular, cargo fetch would only download dependencies that would be compiled by cargo build for the given target(s), and it would avoid downloading the dependencies that wouldn't be compiled by cargo build.

[briansmith]

I see that cargo build does this already: It won't download a crate that it won't build, AFAICT. So, I think it should be straightforward to add a --target option to cargo fetch since presumably cargo build is already somehow passing a target to the implicit cargo fetch it does.

[bmwill]

I'm thinking of picking this up, unless someone else is already working on it.

I've spent a couple hours looking through the code which does the package/dependency filtering in cargo build (which lives in unit_dependencies.rs) and I think I understand how it could be applied to cargo fetch. Would it make sense to simply re-use that logic even though it appears to be more specialized for compilation (since it lives in the cargo_rustc module) as opposed to reimplementing the filtering of dependencies just for fetch?

[DarkDrek]

This seems to be done so issue can be closed.

[alexcrichton]

Indeed!