Excluding a package from workspace still pulls dependency

[SanchayanMaity]

In gst-plugins-rs, the workspace Rust version is at 1.83 and edition at 2021. One package in the workspace, gst-plugin-spotify to be exact, depends on librespot which has a MSRV of 1.85 and uses edition 2024.

For testing with 1.83 in CI, we expected to skip the plugin/package from cargo nexttest by specifying --exclude gst-plugin-spotify. However, it seems we encounter a failure while trying to download a dependency as below. Trying filter set DSL did not help either.

    error: failed to download `librespot-oauth v0.7.0`

    Caused by:
      unable to get packages from source

    Caused by:
      failed to parse manifest at `/home/core/.cargo/registry/src/index.crates.io-6f17d22bba15001f/librespot-oauth-0.7.0/Cargo.toml`

    Caused by:
      feature `edition2024` is required

      The package requires the Cargo feature called `edition2024`, but that feature is not stabilized in this version of Cargo (1.83.0 (5ffbef321 2024-10-29)).
      Consider trying a newer version of Cargo (this may require the nightly release).
      See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2024 for more information about the status of this feature.

To be fair, this can also be triggered with either of the below while being on 1.83. Specifying --no-deps to cargo metadata does fine.

cargo metadata
cargo tree -p librespot-oauth --invert

AFAIU, there is some problem around metadata retrieval for unused packages or packages we would like to skip. Looked for some existing tickets like https://github.com/nextest-rs/nextest/issues/1298, but, the resolution was not clear.

Is this expected or do we miss something?

[sdroege]

With 1.83 we're using cargo nextest 0.9.94, which includes the fix for https://github.com/nextest-rs/nextest/issues/1298 at least.

[sunshowers]

Thanks for the report. This most likely occurs due to nextest needing to fetch cargo metadata, which doesn't have a way to exclude packages from consideration. I don't think nextest can do anything here without support in cargo metadata for this use case.

Specifying --no-deps to cargo metadata does fine.

Nextest needs dependency information from cargo metadata for several purposes such as filtersets, unfortunately.

I don't plan to work on this, but if you'd like to work with Cargo upstream to make this better I'd be happy to incorporate the corresponding improvements into nextest.