New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Call for Testing: MSRV-aware resolver #13873
Comments
Initial impressions, when I ran this command in a project (https://github.com/Nemo157/u2f-touch-detector @ > CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo -Zmsrv-policy generate-lockfile
Updating crates.io index
Locking 101 packages to latest Rust 1.79.0 compatible versions
Adding addr2line v0.21.0 (latest: v0.22.0)
Adding gimli v0.28.1 (latest: v0.29.0)
Adding io-lifetimes v1.0.11 (latest: v2.0.3)
Adding linux-raw-sys v0.4.13 (latest: v0.6.4)
Adding nix v0.27.1 (latest: v0.28.0)
Adding nu-ansi-term v0.46.0 (latest: v0.50.0)
Adding object v0.32.2 (latest: v0.35.0)
Adding owo-colors v3.5.0 (latest: v4.0.0)
Adding regex-automata v0.1.10 (latest: v0.4.6)
Adding regex-syntax v0.6.29 (latest: v0.8.3)
Adding windows-sys v0.48.0 (latest: v0.52.0)
Adding windows-targets v0.48.5 (latest: v0.52.5)
Adding windows_aarch64_gnullvm v0.48.5 (latest: v0.52.5)
Adding windows_aarch64_msvc v0.48.5 (latest: v0.52.5)
Adding windows_i686_gnu v0.48.5 (latest: v0.52.5)
Adding windows_i686_msvc v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_gnu v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_gnullvm v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_msvc v0.48.5 (latest: v0.52.5) Looking into the lockfile this had nothing to do with the MSRV clause though, this is just the transitive version requirements of my dependencies, so the same messages are emitted without the msrv-policy. It seems like there should be some distinction in these messages about why the latest isn't being selected. I tried to force a MSRV conflict by extracting |
I came up with a different scheme for testing a current-rustc MSRV conflict, I overlaid a nightly cargo version on top of a stable 1.72 toolchain (I have no idea if something like this is possible with rustup, but it's easy to do with > nix shell pkgs#rust-bin.stable.'"1.72.0"'.minimal
> nix shell pkgs#rust-bin.nightly.latest.cargo
> cargo --version && rustc --version
cargo 1.80.0-nightly (0ca60e940 2024-05-08)
rustc 1.72.0 (5680fa18f 2023-08-23) Regenerating the lockfile seemed to happen just as before, but correctly detected 1.72: > CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo -Zmsrv-policy generate-lockfile
Updating crates.io index
Locking 101 packages to latest Rust 1.72.0 compatible versions
... same as before ... Trying to build then failed > cargo check
error: rustc 1.72.0 is not supported by the following packages:
clap@4.5.4 requires rustc 1.74
clap_builder@4.5.2 requires rustc 1.74
clap_derive@4.5.4 requires rustc 1.74
clap_lex@0.7.0 requires rustc 1.74
Either upgrade rustc or select compatible dependency versions with
`cargo update <name>@<current-ver> --precise <compatible-ver>`
where `<compatible-ver>` is the latest version supporting rustc 1.72.0 I would have expected a warning about this when generating the lockfile (maybe even mentioning the latest compatible version so I didn't have to go searching the repository for when Setting the minimum requirement on > cargo add clap@4.4.18
Updating crates.io index
Adding clap v4.4.18 to dependencies
Features:
...
> CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo -Zmsrv-policy generate-lockfile
Updating crates.io index
Locking 101 packages to latest Rust 1.72.0 compatible versions
Adding addr2line v0.21.0 (latest: v0.22.0)
Adding clap v4.4.18 (latest: v4.5.4)
Adding clap_builder v4.4.18 (latest: v4.5.2)
Adding clap_derive v4.4.7 (latest: v4.5.4)
Adding clap_lex v0.6.0 (latest: v0.7.0)
... rest same as before ...
> cargo check
...
Finished `dev` profile [unoptimized + debuginfo] target(s) in 12.62s |
We have two challenges with the reporting
As for having too high of version requirements, I wonder how often that will be happening in practice. Users get their version requirements from
Hopefully this isn't a high traffic workflow that we have to worry about. Instead, we also expect people to see these messages when they are intentionally not using the MSRV-aware resolver where there is nothing actionable from the messages and they will likely annoy people. I think I'd be ok with experimenting with adding to |
This works great for the $ CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo +nightly -Zmsrv-policy generate-lockfile
Updating crates.io index
Locking 36 packages to latest Rust 1.63 compatible versions
Adding home v0.5.5 (latest: v0.5.9)
Adding linux-raw-sys v0.4.13 (latest: v0.6.4)
Adding regex v1.9.6 (latest: v1.10.4)
Adding regex-automata v0.3.9 (latest: v0.4.6)
Adding regex-syntax v0.7.5 (latest: v0.8.3)
Adding windows-sys v0.48.0 (latest: v0.52.0)
Adding windows-targets v0.48.5 (latest: v0.52.5)
Adding windows_aarch64_gnullvm v0.48.5 (latest: v0.52.5)
Adding windows_aarch64_msvc v0.48.5 (latest: v0.52.5)
Adding windows_i686_gnu v0.48.5 (latest: v0.52.5)
Adding windows_i686_msvc v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_gnu v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_gnullvm v0.48.5 (latest: v0.52.5)
Adding windows_x86_64_msvc v0.48.5 (latest: v0.52.5)
$ cargo +1.69.0 build
Compiling rustix v0.38.34
Compiling bitflags v2.5.0
Compiling linux-raw-sys v0.4.13
Compiling home v0.5.5
Compiling either v1.11.0
Compiling which v5.0.0 (~/Documents/source_code/which-rs)
Finished dev [unoptimized + debuginfo] target(s) in 1.00s |
What is the syntax for configuring this using Is there an option for using dependencies compatible with whichever rustc the user happens to be using? |
This should work. [unstable]
msrv-policy = true # or put this in CLI `-Zmsrv-policy`
[resolver]
something-like-precedence = 'something-like-rust-version' |
Call for testing
The MSRV-aware resolver part of this RFC is implemented and we are wanting to collect feedback in preparation for stabilization.
The goal is to allow you to manage your dependencies without having to manually ensure they are compatible with your rust-version
package.rust-version
if set, otherwiserustc --version
Basic steps:
Requirements:
betastableAt minimum, run
$ CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo +nightly -Zmsrv-policy generate-lockfile
NOTE: The config field name and values are intentionally not ready yet. This is being tracked in #13540. This will be resolved before stabilization
Feel free to run any other commands and workflows with
CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version
(proposed behavior) orCARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-maximum
(existing behavior) with+nightly -Zmsrv-policy
.cargo/config.toml
workspace.resolver = "3"
orpackage.edition = "2024"
withcargo-features = ["edition2024"]
in yourCargo.toml
See also Documentation
Please leave feedback on this issue
The text was updated successfully, but these errors were encountered: