nextest-rs/nextest

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.