Add `rustup ensure` which doesn't check for updates

[jyn514]

Problem you are trying to solve

I have an integration test that requires ~10 different versions of Rust to be installed. In that test, I run rustup toolchain install --no-self-update version1 version2 .... This takes about 5 seconds to run, making my integration tests slower.

I see the following message from rustup as it does this:

info: syncing channel updates for '1.72-aarch64-apple-darwin'
info: latest update on 2023-09-19, rust version 1.72.1 (d5c2e9c34 2023-09-13)
info: component 'llvm-tools' for target 'aarch64-apple-darwin' is up to date
  1.72-aarch64-apple-darwin unchanged - rustc 1.72.1 (d5c2e9c34 2023-09-13)

I infer from this that rustup is touching the network every time I run rustup install. I don't want this behavior; I merely want to make sure the toolchain is installed at all, not that it's up to date. As far as I can tell, there's no flag for rustup toolchain install to configure this.

Solution you'd like

Add a new rustup ensure command (or rustup install --no-update option) which tells rustup to only touch the network if the toolchain doesn't exist on disk.

Notes

rustup 1.28.2 (e4f3ad6 2025-04-28)

[jyn514]

I also note that rustup is doing this sequentially, rather than fetching all the manifests in parallel, so it's even slower than it could be given the CLI interface. Happy to make a PR fixing that if it's welcome.

[rami3l]

@jyn514 Thanks for the issue!

I am a bit confused about your proposal since I assume it is natural for rustup toolchain install to fetch something from the internet. The rationale is that it should result in the same configuration regardless of the initial state (let's say the current stable is 1.90.0, then rustup toolchain install stable should install exactly that).

Did you mean you only wanted to check for toolchain names? If that's the case, maybe processing the output of rustup toolchain list -q would be a better idea?

As for the sequentiality, it's quite possible that we are missing a lot of optimization opportunities, since the codebase has just moved from sync to async. I'd be happy to review improvements in that regard :)

[jyn514]

Did you mean you only wanted to check for toolchain names? If that's the case, maybe processing the output of rustup toolchain list -q would be a better idea?

That'll work, I'll probably end up doing that. It has some caveats that wouldn't come from putting it first-class in rustup: I'll need to filter to only the toolchains that aren't installled (in case there's a partial install), and it's non-trivial to parse because rustup lists the fully expanded canonical name instead of the shortname. But that's doable.

I am a bit confused about your proposal since I assume it is natural for rustup toolchain install to fetch something from the internet. The rationale is that it should result in the same configuration regardless of the initial state (let's say the current stable is 1.90.0, then rustup toolchain install stable should install exactly that).

I don't expect this behavior from install. I only expect it from update. I expect install to be idempotent once the toolchain is installed.

[djc]

I don't expect this behavior from install. I only expect it from update. I expect install to be idempotent once the toolchain is installed.

This seems reasonable to me. Also parsing the output of list seems relatively cumbersome compared to us providing the equivalent of --no-update.

[ChrisDenton]

I wouldn't want a new subcommand for this because having something that's like install but slightly different seems more confusing to me. But making it an option sounds reasonable.

[rami3l]

I don't expect this behavior from install. I only expect it from update. I expect install to be idempotent once the toolchain is installed.

This seems reasonable to me. Also parsing the output of list seems relatively cumbersome compared to us providing the equivalent of --no-update.

@jyn514 @djc If I were to rebuild rustup from scratch then indeed I would go with that interpretation. Given the fact that there are absolutely a certain amount of devs who are relying on the old behavior, I agree with adding a new option.

[djc]

Given the fact that there are absolutely a certain amount of devs who are relying on the old behavior, I agree with adding a new option.

Have you seen this in previous issues? Where have you noticed this?

[rami3l]

Given the fact that there are absolutely a certain amount of devs who are relying on the old behavior, I agree with adding a new option.

Have you seen this in previous issues? Where have you noticed this?

@djc The biggest example is https://github.com/dtolnay/rust-toolchain/blob/6d653acede28d24f02e3cd41383119e8b1b35921/action.yml#L92-L94. The current behavior brings consistency inside and outside of bring-your-own-dockerfile workflows.

Basically every GitHub CI relying the above workflow to install the stable toolchain will get the latest stable exactly because of this mechanism.

Of course it'd better be --update instead of --no-update in the first place, and probably rustup update should fail if the toolchain in question is not installed, but alas...