Comments (9)
This works great for the which
crate. We've previously struggled with this issue, so thanks a bunch for devoting attention to it!
$ 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
from cargo.
Initial impressions, when I ran this command in a project (https://github.com/Nemo157/u2f-touch-detector @ e12096fe3571ac3b7c501dca9f9d452b2b9f0e4c
) it emitted what looked like a bunch of warnings to me:
> 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 [email protected]
into a local directory, adding a patch.crates-io
pointing to it, and bumping it to have version = "0.6.13"
and rust-version = "1.80.0"
. Running the above command seemed to ignore that and still chose to use the local 0.6.13 version instead of the remote 0.6.12; but maybe there's something specifically about patch/path dependencies causing that.
from cargo.
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 oxalica/rust-overlay
with nix):
> 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:
[email protected] requires rustc 1.74
[email protected] requires rustc 1.74
[email protected] requires rustc 1.74
[email protected] 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 clap
's MSRV was last bumped).
Setting the minimum requirement on clap
back to a compatible version, regenerating the lockfile and building worked, but as I mentioned above there's no distinction that the reason the latest wasn't chosen was MSRV related rather than version constraint related
> cargo add [email protected]
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
from cargo.
We have two challenges with the reporting
- We don't actually know why the resolver made the choices it did (#7929)
- We need to be misery in our output to not overwhelm the user so that they can't find the information that would be useful for them
As for having too high of version requirements, I wonder how often that will be happening in practice. Users get their version requirements from
cargo add
: will auto-select a compatible version- crates.io: shows what the MSRV is
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 Adding
line a requires Rust 1.74.0
but also saying what an alternative is might be a bit too noisy.
from cargo.
What is the syntax for configuring this using .cargo/config.toml
? I could not figure it out.
Is there an option for using dependencies compatible with whichever rustc the user happens to be using?
from cargo.
What is the syntax for configuring this using
.cargo/config.toml
? I could not figure it out.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'
from cargo.
As part of a fairly simple cli tool I was making (https://github.com/savente93/cite-me-bro) I tried this out, and running it with the env vars seems to work fine.
CARGO_RESOLVER_SOMETHING_LIKE_PRECEDENCE=something-like-rust-version cargo -Zmsrv-policy generate-lockfile
Updating crates.io index
Locking 85 packages to latest Rust 1.75.0 compatible versions
Adding windows-core v0.52.0 (latest: v0.56.0)
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)
However, I'm having some trouble getting it to work with the Cargo.toml
After adding the keys above to my Cargo.toml the update itself works just fine:
$ cargo update
Updating crates.io index
Locking 0 packages to latest Rust 1.75.0 compatible versions
note: pass `--verbose` to see 10 unchanged dependencies behind latest
However subsequent builds results in the following warning:
❯ cargo t
warning: unused manifest key: resolver
warning: unused manifest key: unstable
I'm not sure if this is something I'm doing wrong, or an unintended consequence.
For reference here is my Cargo.toml:
cargo-features = ["edition2024"]
[package]
name = "cite-me-bro"
version = "0.1.0"
edition = "2024"
rust-version = "1.75.0"
[unstable]
msrv-policy = true # or put this in CLI `-Zmsrv-policy`
[resolver]
something-like-precedence = 'something-like-rust-version'
[dependencies]
...
and my versions
❯ rustup check
stable-x86_64-unknown-linux-gnu - Up to date : 1.78.0 (9b00956e5 2024-04-29)
nightly-x86_64-unknown-linux-gnu - Up to date : 1.80.0-nightly (f67a1acc0 2024-06-01)
rustup - Up to date : 1.27.1
from cargo.
That configuration is for .cargo/config.toml
not Cargo.toml
resolver.something-like-precedence
config field
https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#msrv-policy
from cargo.
whoops, my bad, I'll try again if I have time today
from cargo.
Related Issues (20)
- Registry Authentication does not mention non-globle credential-provider
- Make `bench` profile set `debug = true` by default HOT 2
- `debug-assertions` are implicitly disabled when running `cargo test` with `opt-level=3` set from `rustflags` HOT 3
- `cargo vendor` misses some files HOT 4
- Export environment `OUT_DIR` to proc-macro. HOT 1
- Port from bespoke assertions of snapbox HOT 7
- Tests fail if directory contains special characters HOT 2
- Get cargo environment without running code
- Build scripts only get `RUSTFLAGS` when not passing `--target` HOT 2
- Optionally generate "dep-info for external build system integration" for test and example binaries HOT 7
- Sharing TARGET_DIR leads to spurious missing items HOT 2
- `cargo --list` shows blank explanation for the `miri` command on windows HOT 3
- Cargo incorrectly identifies transitive dependency versions when compiling new dependencies HOT 2
- Allow "--extern" rustc flags in build script HOT 8
- error: `cargo rustc --lib --message-format=json-render-diagnostics --manifest-path Cargo.toml --release -v --features pyo3/extension-module --crate-type cdylib --` failed with code 101 HOT 1
- Failing to build cargo latest with cargo latest HOT 3
- Cannot `cargo install --path .` HOT 3
- On Windows's are not trimmed from authentication tokens during publish. HOT 1
- test: `with_stderr_(data|contains)` has no effect when chained with `run_expect_error()` HOT 2
- Cargo cannot resolve a dependency using a tag in github HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cargo.