Pre-RFC: MSRV-aware resolver

tools and infrastructure cargo
61

I've gone ahead and created an RFC: RFC: MSRV Resolver by epage · Pull Request #3537 · rust-lang/rfcs · GitHub

62

I think using rustc --version for the default version for MSRV resolution is going to work better.

  1. It's not sufficient to use older dependencies to actually make projects compatible with an older Rust version. There are also lanugage features, libstd changes, edition, cargo features that depend on Rust version. Clippy can't handle it all — there are crates that dynamically detect rustc version and enable features based on that. Testing with cargo +1.xx.x test is the best bet, and defaulting to rustc --version will encourage that.

  2. I'm worried about application developers missing dependency updates without realizing that rust-version in their Cargo.toml holds them back. This isn't just about CVEs, but also getting bugfixes, and the latest documentation on docs.rs matching what they use. I wouldn't want every interaction with a library maintainer to start with an obligatory "have you updated to the latest version of my library? Are you sure? Have you tried with --ignore-rust-version?". Defaulting to rustc --version will mostly work in these cases, since most users use rustup update regularly.

2 Likes
63

Note that I'm focusing conversations on the RFC at this point to make it easier for everyone to follow along

64

I think we should have a warning whenever the selected version is not the latest available compatible version.

65

I had a very unpleasant experience:

I work on old version of Rust, usually I develop my library with dependencies by:

cargo +nightly -Z minimal-versions update

But when I publish my library by cargo publish, I got:

Caused by:
  package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.65.0

Is there cargo publish update dependencies by -Z minimal-versions, or it's best to update the dependent version based on the rust-version.

66

Does cargo publish --no-verify work for you? Perhaps --frozen or --locked would work?

67

Thanks, I use cargo +stable publish to achieve it.

68

I'm assuming whats happening is that you don't commit your lockfile and so cargo publish is generating a new one.

If you aren't aware, we've changed our guidance on lockfiles and imo the way to solve this is to commit your lockfile.

69

It's not necessarily only whether the Cargo.lock is committed. Cargo will only include it in the package if there is a binary crate (either a [[bin]] or an [[example]]), so for lib-only crates the Cargo.lock will never be used when verifying during a publish. (I think this was mentioned somewhere during the discussion about changing the guidance, but afaik hasn't been actually proposed to change).

1 Like
70

We discussed this in today's team meeting and I captured that in an issue I created for this: `cargo publish` of a `[lib]` fails when dependencies exist newer than my toolchain version · Issue #13306 · rust-lang/cargo · GitHub

71

This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.