Updatable toolchain aliases

[Nemo157]

I commonly work with pinned nightlies in projects that require extra components installed, updating the pinned date in one of these projects is a lot of work since I need to find a new nightly that has all the components available. One idea I had to solve this would be to have a sort of local "channel" alias that I can manually update to the latest release of different upstream channels, and have this update use the normal check for all required compenents that happens with channels like nightly.

I think the easiest way to fully explain this would be an example of how I would expect a CLI interaction with this feature to go:

> rustup toolchain add foobar=nightly-2018-10-31
info: syncing channel updates for 'nightly-2018-10-31-x86_64-apple-darwin'
info: latest update on 2018-10-31, rust version 1.31.0-nightly (1cf82fd9c 2018-10-30)
[...]

  foobar installed - rustc 1.31.0-nightly (1cf82fd9c 2018-10-30)

> rustup component add --toolchain foobar clippy
info: downloading component 'clippy'
info: installing component 'clippy'

> rustup update foobar=nightly-2018-11-28
info: syncing channel updates for 'nightly-2018-11-28-x86_64-apple-darwin'
warning: component 'clippy' is not available anymore on target 'x86_64-apple-darwin'
error: some components unavailable for download: 'clippy'

  foobar update failed - rustc 1.31.0-nightly (1cf82fd9c 2018-10-30)

> rustup update foobar=nightly-2018-11-30
info: syncing channel updates for 'nightly-2018-11-30-x86_64-apple-darwin'
info: latest update on 2018-11-30, rust version 1.32.0-nightly (3e90a12a8 2018-11-29)
[...]

  foobar updated - rustc 1.32.0-nightly (3e90a12a8 2018-11-29)

[ijackson]

I would also like something like this.

My +nightly has miri. That means that when I rustup update, I don't get the latest nightly if miri is broken, which is correct.

But when I work on a project that doesn't care about miri but wants the latest latest nightly, I have to manually type in the date, specially installing a pinned version (and then I have to remember, later, to delete it again - and all I have to go on then is the dates and sometimes I can't remember why I have 2022-04-17 or whatever).

Ideally I would like two "toolchain" names, one of which is "nightly with miri" and the other of which is "nightly, don't care about miri". I'd like rustup update to update both of these to the respective latest version (ideally, deduplicating if actual latest has miri).

In order to do this I think all I need is the ability to define a local alias for a "channel". I.e., if I could say rustup toolchain add very-nightly=nightly then presumably it would install current nightly and if I simply didn't say +very-nightly component add miri I would have cargo +very-nightly build using latest, and cargo +nightly miri would still work and everything would be great.

I wonder if this is realted to #2696. Eg if that feature were provided, and had all the update machinery, I could define a "remote custom toolchain" which was actually just the normal URLs with a different name.

[kinnison]

I have been thinking about custom toolchain origins, and also about aliasing and relabelling toolchains in general. I don't have a good answer to all this yet; the start of my thoughts can be found here -https://hackmd.io/X_xhHKHnRnycDDJURv2M4A