Dependency version issues for older Rust

help
1

I lately get a lot of problems with error messages like "Edition 2024" required or "rustc 1.81.0 is not supported by the following package".

Background: For development I use 1.81 as this is the last version that works with CodeLLDB v10, which still displays the content of Vec.
(This is a sidequest, not the main question: I am not sure if there is another way to look into these (Linux Mint) with another debugger, but CodeLLDB stopped supporting Rust, but is still the recommended Debugger).

So I am using 1.81 during development.

Obviously I am using cargo packages, so I am looking for a package which still supports 1.81., e.g. yew = {version = "=0.21" , features = ["csr"] } (crates.io: Rust Package Registry).

But I often find, this does not work.
Yew itself has dependencies, here:
[dependencies.indexmap] features = ["std"] version = "2"

Now, specifying version two will install the newest version below "3", which currently is "2.13.0", but that version now requires rustc 1.82, making Yew requiring 1.82 itself.

I have had this with other packages as well, sometimes I download them and adjust the dependencies.

Another example (do rustup default 1.81 before):
cargo install cargo-msrv --version 0.18.1

error: failed to compile cargo-msrv v0.18.1, intermediate artifacts can be found at `/tmp/cargo-installjNe14K`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Caused by:
  failed to parse manifest at /home/gunnar/.cargo/registry/src/index.crates.io-6f17d22bba15001f/time-core-0.1.8/Cargo.toml

Here the culprit is time-core, a very heavily used package, which only supports Rust 1.81 up to version 0.1.6. It is not even included directly in cargo-msrv, but is a dependency of a dependency.

Question: Is there a way to tell cargo to use only the dependency versions which support a certain rustc version? So in this case the dependency indexmap of Yew would only bump up to 2.11.4?

General discussion:
Should not the crates.io directory regulary check the packages on the included dependencies, so that the Meta-Data shows the correct version (at least at the newest version). Possibly informing the uploader that the requirements have changed?

Personally I am not sure if using "Dependency = "0.12.21" should not default to "=0.12.21" because this is apparently the tested version. Allowing updates is risky. But that seems too late to be changed.

At lease version numbering should be made clearer in the point. A minor update like 0.12.21 to 0.12.22 should never require a higher rustc version or Edition (have seen this). Crates.io could even check this.

2

You can use this command to cargo install whatever is in Cargo.lock:

cargo install cargo-msrv --version 0.18.1 --locked
1 Like
3

Cargo does that since 1.84, assuming your current Rust version as the maximum (MSRV-aware resolver).

This may exist in 1.81 as an unstable feature.

It still doesn't solve all the incompatibilities, because it depends on crates accurately declaring their rust-version, and many crates don't have it (https://lib.rs has MSRV data for all crates if you want to look it up manually).

Unfortunately, anything older than 1.85 is going to be a pain. 1.85 is the default for all new Cargo projects due to being 2024 edition, and 1.85 is in Debian stable, so this is the oldest version that many projects support.

Have you filed bugs about the CodeLLDB problem? Getting a fix in the latest Rust/LLVM may be much easier.

1 Like
4

I'd recommend using a mix of versions. Use the latest version for cargo update, cargo check, cargo clippy, etc and use 1.81 when building binaries which that might be debugged.