New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Basics

What's the name of the package manager?

Rust Toolchain (rust-toolchain)

What language(s) does this package manager support?

It is for the Rust programming language, but the relevant configuration file is in TOML.

How popular is this package manager?

rustup is used by the majority of Rust users, though not everyone is using it with a rust-toolchain.toml file. It is however fairly popular for embedded developers that often rely on nightly features and is used there to pin down nightly release versions to a specific date.

Does this language have other (competing?) package managers?

• Yes (give names).
• No.

cargo handles the dependencies of Rust projects, but not the Rust toolchain version itself, so this shouldn't be seen as competition.

What are the big selling points for this package manager?

Previously, people could use the regex manager with the GitHub releases datasource to achieve something similar, but were limited to pinning stable releases. With this dedicated implementation we support:

• 1.90.0 → 2.0.0 (major version updates)
• 1.90.0 → 1.91.0 (minor version updates)
• 1.90.0 → 1.90.1 (patch version updates)
• nightly-2025-10-10 → nightly-2025-10-11 (nightly version updates)

With rangeStrategy: replace:

• 1.90 → 2.0 (major range updates)
• 1.90 → 1.91 (minor range updates)

With rangeStrategy: pin:

• 1.90 → 1.90.0 (range pinning)
• stable → 1.90.0 (stable channel pinning)
• nightly → nightly-2025-10-11 (nightly channel pinning)

Detecting package files

What kind of package files, and names, does this package manager use?

rust-toolchain.toml (and the legacy rust-toolchain)

Which managerFilePatterns pattern(s) should Renovate use?

/(^|/)rust-toolchain(\.toml)?$/

Do many users need to extend the managerFilePatterns pattern for custom file names?

• Yes, provide details.
• No.

Is the managerFilePatterns pattern going to get many "false hits" for files that have nothing to do with package management?

No

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

No

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML
• Custom (explain below)

The legacy format uses a plain-text channel specifier, but is only supported for the legacy filename (rust-toolchain). rust-toolchain.toml only supports the TOML format.

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

Does the package file have different "types" of dependencies?

• Yes, production and development dependencies.
• No, all dependencies are treated the same.

I chose to use depType: toolchain which makes the following work:

{
  "packageRules": [
    {
      "matchDepTypes": ["toolchain"],
      "rangeStrategy": "pin"
    }
  ]
}

List all the sources/syntaxes of dependencies that can be extracted

I'm not sure I understand this question 🤔

The parser extracts the toolchain.channel field from the TOML file.

Describe which types of dependencies above are supported and which will be implemented in future

Only the channel field is supported as a depType: toolchain dependency.

Versioning

What versioning scheme does the package file(s) use?

It's complicated... 😅

https://rust-lang.github.io/rustup/overrides.html#channel specifies the supported values for this field:

(<channel>[-<date>])|<custom toolchain name>

<channel>       = stable|beta|nightly|<versioned>[-<prerelease>]
<versioned>     = <major.minor>|<major.minor.patch>
<prerelease>    = beta[.<number>]
<date>          = YYYY-MM-DD

Since supporting all of them in a single versioning scheme seemed fairly complicated, I chose two create two new versioning schemes: rust-toolchain and rust-toolchain-nightly

The former supports stable, x.y.z and x.y specifiers. The latter supports nightly and nightly-YYYY-MM-DD specifiers.

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Yes, but only in the form of the stable and nightly constants.

Lookup

Is a new datasource required?

• Yes, provide details.
• No.

A new rust-nightly datasource is added by this pull request, which queries https://rust-lang.github.io/rustup-components-history/x86_64-unknown-linux-gnu/rust.json for the latest available nightly versions.

For stable releases we use the existing GitHub releases datasource.

Unfortunately https://github.com/rust-lang/rust/releases only contains the stable releases, so we have no way of supporting beta releases.

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• Yes, provide details.
• No.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details.
• Yes, some other kind of constraint, provide details.
• No constraints.

Will users need the ability to configure language or other constraints using Renovate config?

• Yes, provide details.
• No.

Artifacts

Does the package manager use a lock file or checksum file?

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

Only the datasource is using a 60min cache.

Generating a lockfile from scratch

Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch.
Can the package manager generate a lockfile from scratch?

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

Other

What else should we know about this package manager?

This pull request addresses:

• rust-toolchain version updates #11488
• Support rust-toolchain version updates specifically #24762
• feat(manager/rust-toolchain): Add support for rust toolchain versioning #32432

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

I used Claude Code for the initial discovery, writing down an implementation plan, and for a large portion of the implementation. I did however review each individual step to the best of my abilities and feel fairly confident in the implementation.

I performed a bunch of manual integration testing by running renovate locally. You can see (some of) the results at https://github.com/Turbo87/renovate-rust-test/pulls?q=is%3Apr.