RFC for TUI

Problem you are trying to solve

Hi All,

Lovely tool, i think we can score another win on usability.

I'd like propose the development and eventual inclusion of a simple TUI (Terminal UI) for the rustup tool under a separate sub-command, perhaps something like rustup tui

It would, for starters, include basic functionality like -

1. Listing available rustup versions for installation.
2. Showing versions installed with a single green tick.
3. Showing the currently set version with a green double tick, unsettng any other version.
4. A single key press (say "i" key) to install the highlighted version from the list.
5. A single keypress (say "u" key) for uninstalling the highlighted version.
6. ???

This issue is a RFC (request for comments) for the maintainers and users to explore that if i (we?) take up the development of this feature -

1. Would this be something that the team would be open to including in the tool? (i am not sure of the scope of the tool)
2. is this a functionality that users would want?
3. Would it make using the tool easier / more pleasant experience for (atleast some) users, thus amplifying the rust-language spirit of -

"A language empowering everyone, to build reliable and efficient software"

Solution you'd like

Well, what i have in mind is something along the lines of -

The gif is from the Haskell install tool GHCup's webpage

I am a top contributor to GHCup and currently picking up Rust thus the idea of porting the TUI functionality from it to rustup.

Looking forward
-Arjun

Notes

i'll have to figure out how it'll be implemented and the scope of it but i think rust already has some pretty good terminal-ui libraries.

One downside of the GHCup version of TUI is that it doesn't work on Windows yet, i don't think that'll be the case with the rust libraries.

Start by reviewing the proposed rustup tui subcommand and the existing rustup command scope. Compare the referenced GHCup TUI behavior, including installation, uninstallation, version selection, and Windows support. Done first means maintainers and users agree the feature is wanted and define its scope before implementation.