Tracking: Rustup should not perform implicit installations

[jyn514]

Problem you are trying to solve

here is a transcript of a session with rustup

PS C:\Users\jyn\src\example> rustup toolchain list                              
nightly-x86_64-pc-windows-msvc (default)
1.74-x86_64-pc-windows-msvc
stage1
PS C:\Users\jyn\src\example> rustup uninstall nightly
info: uninstalling toolchain 'nightly-x86_64-pc-windows-msvc'
info: toolchain 'nightly-x86_64-pc-windows-msvc' uninstalled
PS C:\Users\jyn\src\example> rustup toolchain list   
1.74-x86_64-pc-windows-msvc
stage1
PS C:\Users\jyn\src\example> rustc
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2024-01-07, rust version 1.77.0-nightly (b6a8c762e 2024-01-06)
info: downloading component 'cargo'
^C
PS C:\Users\jyn\src\example> rustc +nightly
error: toolchain 'nightly-x86_64-pc-windows-msvc' is not installed
PS C:\Users\jyn\src\example> rustup --version
rustup 1.26.0 (5af9b9484 2023-04-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'

Proposed Solution & Progress

[The following behaviors of the current rustup should be changed:]

• uninstalling the default toolchain happens silently. i would expect either a warning (by the same logic as Give a warning before uninstalling the active/default toolchain, or the last/host target for a toolchain #3319), or for rustup to switch to a different default toolchain.
• running rustc afterwards implicitly reinstalls the toolchain.
• I do not expect rustup to implicitly install in any case other than when rust-toolchain.toml is in the current directory. in fact, you can see that rustc +nightly does not implicitly install, only rustc by itself. [@rami3l: We shouldn't do even that, instead we should let the user explicitly install the required toolchain with a command.]
• running rustup --version also silently installs.
• running rustup show also silently installs.

Notes

rustup 1.26.0 (5af9b94 2023-04-05)

Tasks

• fix(rustup-mode)!: don't install toolchain on rustup --version #3948

[rami3l]

Regarding implicit installs, as a user it seems obvious to me that commands that I expect be purely informational wouldn't modify my system under any circumstances:
rustup show
rustup check
rustup which
rustup --version
rustup --help

It wouldn't really bother me to have commands that already modify the behaviour of my system in some way automatically install things, and would often be a pleasant convenience:
rustup run
rustup ensure?
rustup update
rustup target
rustup default
rustup toolchain
rustup component
rustup override

I think rustup doc could go either way.
by @ickk in #1397 (comment)

[abonander]

I've been looking through related issues and PRs for the last 20 minutes and I still don't have a straight answer:

• Is rustup show meant to automatically install the toolchain in rust-toolchain.toml?
• If so, is this behavior going to change without warning in a future update?
• If not, what command should I use in CI to ensure the correct version of Rust is installed?

I was sent to #1397 by https://rust-lang.github.io/rustup/overrides.html#overrides but that issue is now closed. I'm here because this appears to be the latest one with activity and I didn't want to necro.

[rami3l]

I've been looking through related issues and PRs for the last 20 minutes and I still don't have a straight answer:

• Is rustup show meant to automatically install the toolchain in rust-toolchain.toml?
• If so, is this behavior going to change without warning in a future update?
• If not, what command should I use in CI to ensure the correct version of Rust is installed?

I was sent to #1397 by https://rust-lang.github.io/rustup/overrides.html#overrides but that issue is now closed. I'm here because this appears to be the latest one with activity and I didn't want to necro.

@abonander Hi! #1397 has been closed and the fix will be shipped in Rustup v1.28.0 (see #3225's milestone).

The plan for this release also includes introducing a rustup toolchain ensure command that installs the toolchain.

We don't currently have a specific timeline for a new release though as the team has limited bandwidth right now, I'm really sorry 🙇

[abonander]

@rami3l I still don't understand. I saw #3225 and the discussion was very difficult to follow as it mixed conversations about the behavior of the command with those concerning the output of the command.

Could I just get a plain answer to my question, please?

[Veykril]

(not reading up on the thread but as I was pinged) r-a would likely benefit from an explicit install step. I'm annoyed with checking out a repo that has a toolchain override in it just for r-a to hide the installation behind a fetching metadata step as its being installed while r-a invoked cargo metadata. Even better would be if we could query whether there is an override for the given dir so we could prompt the user (if desired, otherwise fallback to installing ourselves). Likewise was was said, having rustup management integration in the IDE would be nice as well (which would require querying more state about rustup things as well)

Oh also being able to query whether the toolchain for the dir needs to be installed of course

[rbtcollins]

@Veykril #3434 is probably of interest too then :)

[djc]

tl;dr, I think this is being over-thought! do we have any actual data of people using main and being unhappy with it?

Well, it's a large change and I could see how people get frustrated with the experience hit (similar to @samestep). I think effectively no one is using main. But I guess we could just release it and see how it goes.

[rami3l]

I think effectively no one is using main.

@djc That's not entirely true: I use it as my daily driver :]

And from my experience, not many repos I work with use toolchain overrides, so I'm feeling okay anyway in this regard.

But I guess we could just release it and see how it goes.

We have a test driving phase to do before going live, so I hope this will help in terms of collecting user feedback.

[djc]

I think effectively no one is using main.

@djc That's not entirely true: I use it as my daily driver :]

Note the use of "effectively". 😉

[djc]

Okay, let's close this and see what happens during the beta period.

[LukeMathWalker]

I'm just catching up with this whole conversation as a person who routinely relies on rustup show in Docker files to trigger a toolchain installation according to what's inside the rust-toolchain.toml file.
What would be the recommended upgrade path for me? What command should I invoke after this update?

I explicitly don't want to perform any compilation, so invoking cargo commands like check or build is not the way forward.

[ChrisDenton]

rustup install

[rami3l]

I'm just catching up with this whole conversation as a person who routinely relies on rustup show in Docker files to trigger a toolchain installation according to what's inside the rust-toolchain.toml file.

What would be the recommended upgrade path for me? What command should I invoke after this update?

I explicitly don't want to perform any compilation, so invoking cargo commands like check or build is not the way forward.

@LukeMathWalker You'd do rustup toolchain install/rustup install (without any arguments) to manually install the active toolchain starting from v1.28.0. I promise we'll deliver the new release notes with a huge emphasis on this change.

[LukeMathWalker]

I'm just catching up with this whole conversation as a person who routinely relies on rustup show in Docker files to trigger a toolchain installation according to what's inside the rust-toolchain.toml file.
What would be the recommended upgrade path for me? What command should I invoke after this update?
I explicitly don't want to perform any compilation, so invoking cargo commands like check or build is not the way forward.

You'd do rustup toolchain install (without any arguments) to manually install the active toolchain starting from v1.28.0. I promise we'll deliver the new release note with a huge emphasis on this change.

Has that been changed recently? Or was it always an option to invoke rustup toolchain install without any arguments?
Because it is highly non-obvious if going off what's returned by rustup toolchain install --help.

[rami3l]

Has that been changed recently? Or was it always an option to invoke rustup toolchain install without any arguments? Because it is highly non-obvious if going off what's returned by rustup toolchain install --help.

@LukeMathWalker It's a recent change in #3983. The actual syntax is suggested by @ChrisDenton IIRC.

We have also updated the help message:

> rustup --version
rustup 1.27.1+445 (15a7ec40f 2024-09-09)
[..]

> rustup toolchain install --help
Install or update the given toolchains, or by default the active toolchain

Usage: rustup[EXE] toolchain install [OPTIONS] [TOOLCHAIN]...
[..]

[rami3l]

I am looking forward to this change, so thanks for working on it

re: breakage

Might I suggest adding the new behaviour (#3983), and then waiting a release or two before completely removing the implicit installs? My concern is having a path with some continuity; rustup toolchain install on <= 1.27.1 is an error, but after >= 1.28 it will be an error not to do so, leaving no grace period.

If there is need - perhaps some tool that is blocked waiting on the new behaviour - during the transitional period an extra flag could be added to opt-out of implicit installs, at the risk of some complexity.
#3985 (comment)

@ickk It's a perfectly reasonable suggestion. Let's think about the available options together and find out how to do this properly.

[rami3l]

I am looking forward to this change, so thanks for working on it
re: breakage
Might I suggest adding the new behaviour (#3983), and then waiting a release or two before completely removing the implicit installs? My concern is having a path with some continuity; rustup toolchain install on <= 1.27.1 is an error, but after >= 1.28 it will be an error not to do so, leaving no grace period.
If there is need - perhaps some tool that is blocked waiting on the new behaviour - during the transitional period an extra flag could be added to opt-out of implicit installs, at the risk of some complexity.
#3985 (comment)

@ickk It's a perfectly reasonable suggestion. Let's think about the available options together and find out how to do this properly.

@ickk Do you think rustup show active-toolchain || rustup toolchain install will suffice?*

• If you're on the old version, the first command should install the active toolchain and return true, short-circuiting the second;
• If you're on the new version, the first command should return false if the active toolchain is not installed, causing the second to ensure its installation.

*: I'm not sure about the corresponding PowerShell syntax, maybe the following? (cc @ChrisDenton)

$(rustup show active-toolchain | Out-Host; $?) -or $(rustup toolchain install | Out-Host; $?)

[ChrisDenton]

What's wrong with using rustup show active-toolchain || rustup toolchain install in powershell?

[rami3l]

What's wrong with using rustup show active-toolchain || rustup toolchain install in powershell?

@ChrisDenton I did some more research; looks like that's a new syntax in PS7, and I must have been looking at some old literature. I'm not sure how we should properly suggest this for Windows users in general, is || widespread enough as for now?

[ChrisDenton]

Oh for old powershell I'd do it like:

rustup show active-toolchain; if ($LASTEXITCODE -ne 0) { rustup toolchain install }