Update cargo dependencies based on rust-version

[epage]

Tell us more.

Packages in the rust community can specify their minimum supported rust version via Cargo.tomls package.rust-version field. In this case, users usually want their version requirements in Cargo.toml and the pinned versions in Cargo.lock to be compatible with package.rust-version.

Exceptions

• Pinned versions don't need to be compatible because a separate CI job will generate a new Cargo.lock to verify everything is compatible
• Some projects have optional dependencies with higher-than-specified rust-versions
• Some projects might decide that their dev-dependencies can be higher than their rust-version

Things can get a little messy when a [workspace] has multiple rust-versions in it, like cargo itself (since the field is on a per-package basis).

They can also specify their development version via rust-toolchain.toml files. In these cases, version requirements and pinned versions should always be compatible.

Resources

• Access to a dependencies rust-version (if set)
  • Via Cargo.toml in the .crate file
  • In the Index (added in last year, entries were backfilled for all previously published versions)
  • Maybe in the crates API?
• RFC: Make Cargo respect minimum supported Rust version (MSRV) when selecting dependencies rust-lang/rfcs#3537 updates cargo's built-in dependency resolution to prefer compatible dependencies (may be turned off)
• The proposed cargo update --breaking flag (replacing third-party cargo upgrade) will pick compatible versions (may be turned off)

[rarkins]

In Renovate terminology we need to do this:

1. Ensure that the cargo manager extracts constraints.rust if present. I'm not sure if that's per-repo, per-file, or even per-dependency (which doesn't seem to make sense)
2. Ensure that Renovate has the capability to identify when that rust version has an upgrade available
3. Ensure that the crate datasource returns constraints.rust for each version if present

The above 3 points can be converted into separate feature requests as necessary.

These combined would then enable us to support constraintsFiltering=strict for rust dependencies

I think users will need to take care of the exceptions you mention sing packageRules.

Further:

• Renovate does not run CLI tools as part of the lookup process, e.g. cargo update. It will continue using the existing approach
• Renovate will not be enforcing this for transitive dependencies - any problems there would be found during the cargo lock update process and added to the PR. Renovate instead will rely on each package accurately representing their rust compatibility - including for transitive dependencies.

[epage]

Ensure that the cargo manager extracts constraints.rust if present. I'm not sure if that's per-repo, per-file, or even per-dependency (which doesn't seem to make sense)

Cargo tracks the constraint per package in Cargo.tomls package.rust-version field

Ensure that Renovate has the capability to identify when that rust version has an upgrade available

I'm not too sure what this is referring to. Are you talking about also supporting updating of package.rust-version? That seems orthogonal to my request but it'd be a big help. I currently use regex managers for this.

Renovate will not be enforcing this for transitive dependencies - any problems there would be found during the cargo lock update process and added to the PR. Renovate instead will rely on each package accurately representing their rust compatibility - including for transitive dependencies.

It goes against guidelines for packages to constrain their dependencies for rust-version, instead each package is expected to maintain a Cargo.lock to track an instance of the dependencies that they want to develop with. However, rust-lang/rfcs#3537 will allow cargo to do the constraining implicitly for transitive dependencies. While you don't use cargo update to modify dependencies in Cargo.toml, I think I have observed that a command is run to sync the Cargo.lock with Cargo.toml, so this should just work. However, you'll likely want to enable/disable cargo's implicit constraining based on the user setting for constraining.

[rarkins]

Sorry for the delay in getting back to you.

I've created #26314 in order for Renovate to detect/extract the rust-version if present in a cargo.toml. Please comment there if there's anything I've missed.

Similarly I've created #26315 in order for Renovate to return the declared rust_version if present in the crate metadata. Could you explain what you meant by "It goes against guidelines for packages to constrain their dependencies for rust-version"? i.e. presumably you are not referring to the rust_version field in metadata.

When we combine these two features, we could for example know:

• The repository/package we are renovating declares support for 1.56 or later
• Dependency X has an update available but that newer version only supports 1.61 or later, so it is not fully compatible

I suspect that different users and projects will have different preferences here. For example some projects will want to treat this very strictly and suppress the update, while others might want the update and ask Renovate to bump the Rust version too. I also suspect we'll find many cases where the current version of a dependency is technically incompatible with the project, so maybe there's no point withholding an update to a dependency if the current version of the dependency is similarly incompatible.

[epage]

Could you explain what you meant by "It goes against guidelines for packages to constrain their dependencies for rust-version"? i.e. presumably you are not referring to the rust_version field in metadata.

I was interpreting "Renovate instead will rely on each package accurately representing their rust compatibility - including for transitive dependencies." to mean that dependency version requirements should be defined to only select dependencies that have compatible MSRVs. Putting non-semver upper bounds on version requirements, especially for MSRV, makes crates incompatible against each other and we've added guidelines telling people not to do it.'

I suspect that different users and projects will have different preferences here. For example some projects will want to treat this very strictly and suppress the update, while others might want the update and ask Renovate to bump the Rust version too. I also suspect we'll find many cases where the current version of a dependency is technically incompatible with the project, so maybe there's no point withholding an update to a dependency if the current version of the dependency is similarly incompatible.

In working on the proposal for rust-version,. things are complicated.

The baseline assumption is that version requirements (Cargo.toml) need to include a version of your dependency that is compatible with your rust-version. We plan to make cargo add auto-generate version requirements like this. However, there are corner cases where people may intentionally choose to make them higher, like a dev-dependency or an optional dependency that you document invalidates your claim in rust-version. From what I've seen of Renovate, constraining that specifically would be complicated so it seems like only offering rust-version compatible upgrades and just not downgrading when a user picks higher would be the easiest way to deal with this.

It is an interesting idea to also offer auto-bumping rust-version to enable a dependency update.

Things are more murky for the resolved / realized dependency tree (Cargo.lock). There are two main workflows: users who apply rust-version to local development and so Cargo.lock should be compatible with rust-version and users who only apply rust-version to dependents and require the latest version of Rust for local development and want the absolute latest Cargo.lock. However much you run cargo to manage Cargo.lock (seems to be done sometimes because I've gotten cargo errors back before), the proposal is for there to be a setting maintainers can apply to repos that will control which Cargo.lock behavior users get from cargo, making it so there isn't as much you need to do.

[rarkins]

I think there's a challenge which all ecosystems face, and I'm not aware of any of them except maybe Go having a process to handle it today.

Let's say you publish a library A, and it depends on library B. You as A should declare your rust-version, let's say it's 1.61. But if you depend on some version of B which has rust-version=1.62 then that's invalid. Your rust-version for A should be 1.62, not 1.61 - because one of your mandatory dependencies does not support 1.61. It would be amazing if this could be supported at the registry-level, but that's quite a challenge.

The reason I say that Go handles this is that the newest versions of Go will bump the "go directive" in go.mod to the minimum supported Go version, including for all transitive dependencies. This means that if you have an invalid go directive declaration then Go will fix it, and if you update a dependency which itself bumps Go version higher than you have, then Go will bump yours too.