When discovering a workspace that excludes the current package, newer or unstable features cause a spurious failure

[manifest]

Problem

Currently, excluded packages require the same resolver version that was set for workspace (members).

We have a virtual workspace with a few packages. Some of packages are excluded from the workspace. We cannot use resolver = "3" version for excluded packages because they cannot be built with Rust 1.85 (they require an earlier version). At the same time, we prefer to use resolver = "3" for all the other packages of the workspace (i.e. workspace members), but that is currently imposible because resolver is a global option that affects all the packages of the workspace (included and excluded).

Steps

In the example bellow, if we set resolver = "3" for the workspace, we wouldn't be able to build excluded packages even though they are not a part of the workspace.

# Cargo.toml
[workspace]
members = ["included01"]
exclude = ["excluded01"]
resolver = "3"

# excluded01/Cargo.toml
[package]
edition = "2018"

❯ cd /path/to/excluded01 && cargo check
error: failed to parse manifest at `/path/to/Cargo.toml`

Caused by:
  `resolver` setting `3` is not valid, valid options are "1" or "2"

Possible Solution(s)

Ignore resolver version that was set for workspace (members) for excluded packages.

Notes

No response

Version

❯ cargo version --verbose
cargo 1.85.0 (d73d2caf9 2024-12-31)
release: 1.85.0
commit-hash: d73d2caf9e41a39daf2a8d6ce60ec80bf354d2a7
commit-date: 2024-12-31
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.3.2 [64-bit]

[epage]

I'm assuming that the cargo check you gave was for an older version of cargo? And the problem is that when we look to see whether excluded01 is a member of the workspace, that cargo fails to parse the manifest, causing the lookup to fail?

In theory, a subset of the workspace package could be loaded to only check the fields necessary for determining membership. However, that would add a lot of complexity. Before we evaluate an option like that, it would be worthwhile to see how essential it is by exploring potential workarounds.

A workaround would be adding a [workspace] table to excluded01. I have wondered about a package.workspace = false value which would be useful for cargo script.

Another workaround is to set resolver.incompatible-rust-versions in .cargo/config.toml which will allow use of the MSRV-aware resolver without affecting MSRV.

[manifest]

I'm assuming that the cargo check you gave was for an older version of cargo?

That’s correct.

For ”excluded01” package, we have Rust version fixed to 1.61 (using rust-toolchain.toml).

❯ cargo --version
cargo 1.61.0 (a028ae42f 2022-04-29)

And the problem is that when we look to see whether excluded01 is a member of the workspace, that cargo fails to parse the manifest, causing the lookup to fail?

It seems like that.

I was surprised to see any error related to the workspace, because my expectation was that by excluding a package from a workspace, we remove any relation to workspace and that calling cargo from the directory of the package would be no different then calling it from a directory of an individual package.

A workaround would be adding a [workspace] table to excluded01.

That one works.

I have wondered about a package.workspace = false value which would be useful for cargo script.

My first instinct was to try some similar option resolver.workspace = false, only to realize that it doesn’t exist :-)

Another workaround is to set resolver.incompatible-rust-versions in .cargo/config.toml which will allow use of the MSRV-aware resolver without affecting MSRV.

With the following example, the same issue remains.

❯ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=allow cargo check
error: failed to parse manifest at `/path/to/Cargo.toml`
Caused by:
  `resolver` setting `3` is not valid, valid options are "1" or "2"

[epage]

And the problem is that when we look to see whether excluded01 is a member of the workspace, that cargo fails to parse the manifest, causing the lookup to fail?

It seems like that.

I was surprised to see any error related to the workspace, because my expectation was that by excluding a package from a workspace, we remove any relation to workspace and that calling cargo from the directory of the package would be no different then calling it from a directory of an individual package.

The problem is that we need to read enough of the manifest to notice the use of exclude. We don't have that intermediate level of parsing that gives us that much information without processing everything.

Another workaround is to set resolver.incompatible-rust-versions in .cargo/config.toml which will allow use of the MSRV-aware resolver without affecting MSRV.

With the following example, the same issue remains.

❯ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=allow cargo check
error: failed to parse manifest at `/path/to/Cargo.toml`
Caused by:
  `resolver` setting `3` is not valid, valid options are "1" or "2"

Switch back to resolver = "2" for the workspace and use

$ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback cargo check

All resolver = "3" does is make fallback the default value for this config field. Old versions of Cargo will ignore the config, avoiding the need for an MSRV bump. This was all designed intentionally this way so we people didn't have to wait 1-2 years before they could start using this feature.

To keep things simple, you can add to your repo a .cargo/config.toml with that set:

[resolver]
incompatible-rust-versions = "fallback"

[manifest]

The problem is that we need to read enough of the manifest to notice the use of exclude. We don't have that intermediate level of parsing that gives us that much information without processing everything.

I see. Thanks for the elaboration.

Switch back to resolver = "2"

I'm OK with the [workspace] option, because it allows me to apply the workaround to the ”excluded01” package only and keep the workspace members updated. Some day there will be a resolver = "4" :-)

[manifest]

Should we keep this issue open?

[epage]

Might be worth to provide a lightning rod for anyone else who has workspace discovery problems to see if there is enough case to re-evaluate this.