Make `rustup update` completely update the default target before working on others

[tgross35]

Problem you are trying to solve

For anyone who has multiple targets installed, completing a rustup update can take quite a while. It seems the order of operations is:

1. Download rust-std for all installed targets
2. Download cargo, rust-src, and other components
3. Download rust-std for the native/default target (?)
4. Download rustc
5. Remove old components
6. Install downloaded components

However, often times only the default target is of immediate interest.

Solution you'd like

Instead, do something like the following order:

1. Move the old toolchain directory to a different name
2. Download and install rustc
3. Download and install rust-std for the default toolchain/target
4. Download and install components
5. Download and install all remaining targets
6. Remove the backup directory

This should make it feasible to start working with the most commonly used target within a couple of minutes while everything else updates in the background.

Notes

No response

[ChrisDenton]

I don't think we currently make a distinction between rust-std and other components when updating so that would need to be changed. Correct me if I'm wrong.

Using a toolchain while components are being installed is tricky because it involves modifying the toolchain directory. Rustup is not currently safe for that kind of thing. Though I think resolving #3937 would help here.

[rami3l]

Using a toolchain while components are being installed is tricky because it involves modifying the toolchain directory. Rustup is not currently safe for that kind of thing. Though I think resolving #3937 would help here.

@ChrisDenton I think #3937 will make this even harder since the client will be blocked when we are installing the active toolchain...

@tgross35 While I do understand your frustrations, I think the right direction to go is something like https://github.com/dtolnay/fast-rustup. Installing toolchains in Rustup is definitely taking much longer than it should, especially if you have access to high-speed internet.

[ChrisDenton]

I mean, we can block only when necessary right? We download to a cache so blocking only needs to happen when moving files from the cache to the toolchain directory. The downloads can happen in the background.

[ChrisDenton]

One thing I'm wondering about is the most important thing to get a new toolchain up and running asap? Or is it to have the old nightly be usable right up until the new nightly is actually ready?

The latter case would be simpler, I think.

[rbtcollins]

The ordering description doesn't make sense to me - last I saw the code we do an entire toolchain at a time. @rami3l - has anything changed around that?

@tgross35 you can do rustup toolchain update stable (or whatever your default is).

A possibly nice little feature is to allow rustup toolchain update --default or some such.

[ChrisDenton]

Oh, I took the OP as meaning about targets. Like if your toolchain has a lot of targets installed then updating all those rust-std components is going to be painful on a slow connection.

[tgross35]

Oh, I took the OP as meaning about targets. Like if your toolchain has a lot of targets installed then updating all those rust-std components is going to be painful on a slow connection.

Indeed, in my original description I used toolchain to refer to channel+target. I updated this to be specific about target, I always use rustup update nightly.