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.

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.

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.

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.