msrv of cargo-util-schemas is higher than necessary (clap-cargo -> cargo_metadata -> cargo-util-schema)

[joshka]

Problem

The rust-version of cargo-util-schema was bumped automatically, which affects the msrv of packages that transitively use this. This compiles fine using rust 1.85 (minimum required for edition 2024)

Dependency chain:

• We use clap-cargo in ratatui for an xtask project
• clap-cargo bumped to 1.86 recently because cargo_metadata bumped
• cargo_metadata bumped because cargo-util-schemas bumped

I'm assuming this will probably repeat next week when the renovate / dependabot changes roll through the system for the 1.88 changes.

This seems like it will cause difficulties in our xtask project which should be able to build against the actual msrv of our project, not that of the xtask deps.

Steps

No response

Possible Solution(s)

It's possible that this is one of those crates where it actually has to match the rust compiler version to work, but if not, it would be probably a good idea to downgrade rust-version on cargo-utils-schema to the actual msrv rather than updating this crate's rust-version in line with the cargo version.

It's possible that one of the earlier libraries shouldn't have bumped, but this is the root of the bump chain.

Pinging @oli-obk and @epage for their input on this as owners of the other crates.
I'm happy to raise issues in the other repos if it makes it easier to capture the pain points there instead of here), but would suggest that we start here with this one and move discussion as necessary.

Notes

There may be similar issues with other crates. I have not checked.

❯ gd                  
diff --git i/crates/cargo-util-schemas/Cargo.toml w/crates/cargo-util-schemas/Cargo.toml
index 2682b65e1..2de531584 100644
--- i/crates/cargo-util-schemas/Cargo.toml
+++ w/crates/cargo-util-schemas/Cargo.toml
@@ -1,7 +1,7 @@
 [package]
 name = "cargo-util-schemas"
 version = "0.10.0"
-rust-version = "1.88"  # MSRV:1
+rust-version = "1.85"                             # MSRV:1
 edition.workspace = true
 license.workspace = true
 homepage.workspace = true

❯ cargo msrv find --min 1.85                       
  [Meta]   cargo-msrv 0.18.4  

Compatibility Check #1: Rust 1.87.0
  [OK]     Is compatible 

Compatibility Check #2: Rust 1.86.0
  [OK]     Is compatible 

Compatibility Check #3: Rust 1.85.1
  [OK]     Is compatible 

Result:
   Considered (min … max):   Rust 1.85 … Rust 1.88.0 
   Search method:            bisect                  
   MSRV:                     1.85.1                  
   Target:                   aarch64-apple-darwin    

Version

[epage]

The cargo team discussed a similar problem for the home crate at #13270 (comment)

The main two MSRVs we maintain are N-0 (core parts of cargo) and N-2 (external facing APIs like build-rs).

Normally, a mitigating factor is a lack of major version bumps as that can allow either an old or new version to be used. However, we use all pub, exhaustive structs for ease of cargo development so we regularly bump our major version. cargo_metadata could do multi-major version ranges but they are a poor experience in cargo and difficult to validate.

Another question is if cargo_metadata is getting enough value out of cargo-util-schemas. I wouldn't recommend copying the PackageIdSpec logic but if its left to callers to use a version of cargo-util-schemas to parse it, then that might work.

[joshka]

Thanks for the background link Ed. The problem there sounds very similar. I figured this might be a problem that had a more general idea behind it, but wasn't sure how best to search.

I'm not across the details of how exactly the metadata and schema fit in as our use case is via the top level crate clap-cargo.

Ratatui's MSRV is soft N-2 (only update when necessary). It sounds like the cargo crates are a hard N-2 which is somewhat incompatible with our soft msrv change policy. Would that be accurate, or have I missed something obvious?

[epage]

Yes, we have a hard MSRV change policy.

Some other things to consider:

• Do you need the latest clap-cargo?
• Does your xtask need to match your MSRV for everything else? cargo-hack is a great tool for multi-MSRV workspaces; we use it in cargo.

[joshka]

Do you need the latest clap-cargo?

No not specifically. Dependabot submitted a PR, which updates it as part of our weekly updates in ratatui/ratatui#1990

Taking a deeper look at why we imported it in the first place, we only use it for clap_cargo::style::CLAP_STYLING, so really we can easily remove clap-cargo as that is an easy to copy constant. I think to resolve our specific problem I'm going to just do that. This leaves this issue as more of a meta problem, which I'd be happy to accept can be closed without any impact unless you want to keep it open to understand / work out if there's any necessary changes to the approaches in the dependency chain here. (I.e. clap-cargo can only be used in situations where the tool has a similar hard N-2 msrv approach, this seems like it's probably ok in many situations).

Does your xtask need to match your MSRV for everything else? cargo-hack is a great tool for multi-MSRV workspaces; we use it in cargo.

We run tests to ensure that our software compiles against our stated rust-version in our CI (currently 1.85). This catches situations where we introduce changes that aren't valid in the version we've stated we use. We also test against stable (and beta to frontrun clippy changes). If our xtask project has a higher version than our MSRV, then to confirm that our MSRV is valid, we would have to install two versions of the rust compiler, one to build the cargo xtask project and one to use while it's running. This is a significant added complexity and fairly fragile to get right.

Edit: actually I'm a little wrong there, we also use cargo_metadata directly from our xtask - mainly to do similar things to what cargo-hack can do against multiple projects. We may be able to get away with replacing that with calls to cargo-hack and fully dropping the transitive dependency here.

[epage]

If the request is gone, then I'm going to go ahead and closed