nextest downloads unused dependencies
Closed this issue · 4 comments
Reproducible environment
OS: Linux (Debian 12 docker image)
Rust: 1.75.0
Nextest: 0.9.67
axum: 0.7.4
Commands to reproduce
cargo new hello_cargo
cd hello_cargo
cargo add --dev axum
cargo test --no-run
cargo nextest list
Current behavior
cargo nextest list
command downloads 20 additional crates without building them:
root@0b80c0d0a4a9:/hello_cargo# cargo nextest list
Downloaded windows-targets v0.48.5
Downloaded addr2line v0.21.0
Downloaded miniz_oxide v0.7.2
Downloaded cfg-if v1.0.0
Downloaded adler v1.0.2
Downloaded wasi v0.11.0+wasi-snapshot-preview1
Downloaded rustc-demangle v0.1.23
Downloaded backtrace v0.3.69
Downloaded serde_derive v1.0.196
Downloaded cc v1.0.83
Downloaded gimli v0.28.1
Downloaded object v0.32.2
Downloaded windows_aarch64_gnullvm v0.48.5
Downloaded windows_x86_64_gnullvm v0.48.5
Downloaded windows_aarch64_msvc v0.48.5
Downloaded windows_i686_gnu v0.48.5
Downloaded windows_x86_64_gnu v0.48.5
Downloaded windows_x86_64_msvc v0.48.5
Downloaded windows_i686_msvc v0.48.5
Downloaded windows-sys v0.48.0
Downloaded 20 crates (8.5 MB) in 1.97s (largest was `windows-sys` at 2.6 MB)
Finished test [unoptimized + debuginfo] target(s) in 0.03s
Expected behavior
cargo nextest list
and another nextest commands shouldn't download useless dependencies: it may speed down the local & CI builds.
Thanks for the bug report!
That's really interesting that cargo test
doesn't download them. Sadly, nextest needs access to cargo metadata
, which does download them -- though I wonder if --filter-platform
can be used to avoid that.
As I can see, --platform-filter
flag is not work:
root@978b9b83a66d:/hello_cargo# cargo nextest list --platform-filter host
Downloaded wasi v0.11.0+wasi-snapshot-preview1
Downloaded adler v1.0.2
Downloaded windows_aarch64_gnullvm v0.48.5
Downloaded rustc-demangle v0.1.23
Downloaded miniz_oxide v0.7.2
Downloaded backtrace v0.3.69
Downloaded windows-targets v0.48.5
Downloaded cfg-if v1.0.0
Downloaded cc v1.0.83
Downloaded addr2line v0.21.0
Downloaded serde_derive v1.0.196
Downloaded windows_x86_64_gnullvm v0.48.5
Downloaded object v0.32.2
Downloaded gimli v0.28.1
Downloaded windows_aarch64_msvc v0.48.5
Downloaded windows_x86_64_gnu v0.48.5
Downloaded windows_i686_gnu v0.48.5
Downloaded windows_i686_msvc v0.48.5
Downloaded windows_x86_64_msvc v0.48.5
Downloaded windows-sys v0.48.0
Downloaded 20 crates (8.5 MB) in 1.47s (largest was `windows-sys` at 2.6 MB)
Finished test [unoptimized + debuginfo] target(s) in 0.03s
root@978b9b83a66d:/hello_cargo#
Interesting, in my tests it does seem to work!
% rm -rf /opt/cargo/registry/cache/index.crates.io-6f17d22bba15001f/
% cargo metadata --filter-platform x86_64-pc-windows-msvc > /dev/null
...
Downloaded 281 crates (26.8 MB) in 0.29s (largest was `ring` at 4.1 MB)
% cargo metadata --filter-platform aarch64-apple-darwin > /dev/null
...
Downloaded 7 crates (205.3 KB) in 0.15s
Oh -- you're referring to nextest's platform-filter
. No, in this case it's actually nextest calling cargo-metadata internally that's at issue here.