Cannot compile crate with cargo <1.71 if any crate in workspace depends on a crate that uses dep: syntax

[nicoburns]

Problem

There is a backwards compatibility hazard with dep: syntax in Cargo.toml files.

• Given a workspace with N crates
• If any of those crates depend (even transitively) on a crate that uses dep: syntax
• Then no crate in the workspace can be compiled with cargo/rustc older than 1.71

This means that a crate that wants to maintain a low MSRV cannot be combined in a workspace with:

• Other crates in the workspace with higher MSRV
• Examples that depend on crates with higher MSRV
• Tooling or scripts that depend on crates with higher MSRV

Steps

No response

Possible Solution(s)

Perhaps there could be a way to include crates in a workspace for the purpose of being accessible with --package and --workspace being possible to set it as a default crate to compile, but without dependencies being unified with the rest of the workspace?

Something like this would also be good for examples which I find generally work better as separate crates except for the fact that you then can't call them with --example.

Notes

This can be worked around by not using workspaces and splitting the repo into separate Cargo projects. But this is not ideal.

Version

Any version of cargo older than 1.71 (1.71 is not affected, 1.70 is)

[epage]

Yes, when working in a multi-MSRV workspace, you have to use the lowest common denominator for

• workspace member manifest files
• config files
• registry dependency index entries
• all other dependency manifest files and maybe their workspace manifest file

There has been some curiosity around allowing separate Cargo.locks within a workspace. This was thought of more in the direction of the feature unification controls (all-or-nothing config for testing purposes). Supporting this for MSRV as well would require more drastic internal changes and maybe a switch to package-by-package controls which might then be a manifest field to control this.

In blessing workspace members to deviate from each other like this, we should also consider how it affects the whole workflow and how far in that direction do we want to take cargo (ie future possibility discussion, not blocking for full design). For example, groups of inheritable configuration has come up in the past.