Add windows gui / msi installer [difficult]

[brson]

To complete the Rust installation experience on Windows we want to be installing rustup via an msi.

Make a proof-of-concept rustup msi installer that embeds libmultirust. The behavior of this msi will be heavily customized - all it does is the standard rustup install, but presented in a windowsy way. To start with it can be really simple:

• On installation, present a screen that says more-or-less what the console installer says now. Have install/cancel buttons.
• After they press install, go to another window that displays whatever status updates we reasonably can as the install is progressing.
• After install show another screen that indicates success.
• Register the uninstaller with windows so it works from the add/remove programs screen.

This will require a lot of refactoring of the existing install code to get it embedded in this new context.

Our options for GUI's will be limited but we can't use something heavy. I'm thinking either something rust-centric like conrod, or just a very thin win32 wrapper.

[brson]

@Boddlnagg It seems reasonable to me that as much of the self_update module as possible is re-written as MSI-isms. Toolchain installation is probably not worth the duplication, and toolchain installation does have rollback-on-fail behavior.

[Boddlnagg]

@brson We could get rid of custom actions completely by creating copies of rustup.exe instead of hardlinks (see DuplicateFiles Action), using RemoveFolderEx for the cleanup and delaying the default toolchain installation until the first start of rustup.exe. The user-selected default would be written to a file or the registry and a message could be shown at the end of the installation process like "When you run rustup for the first time, the default toolchain will be downloaded and installed". That would also eliminate the need of refactoring rustup output and of figuring out the MSVC static linking. Don't know if that would be a satisfying alternative.

[retep998]

I would be okay with the rustup installer not actually installing any toolchains and just installing rustup itself.

[brson]

@Boddlnagg That sounds like a good starting point, though I think ultimately we do want to be in a place where the GUI can be used for all installation tasks - that's what windows users expect. Losing the hardlinks is kind of a drag though. Is it desirable to not have custom actions?

[Boddlnagg]

@brson It is desirable to not have custom actions, because of rollback: When Windows Installer installs a file and would have to overwrite an existing file, it first creates a backup of that file at some hidden location, then installs the new file, then deletes the backup when the installation has completed. We would have to implement this logic ourselves for the "Create Hardlink" custom action in order to support rollback correctly, and I don't know if that's worth it, if we can use machinery that's already there. Do you expect that the number of hardlinks will grow in the future?

A GUI for all installation tasks (i.e. for rustup itself, not just for the initial setup) should not be the goal for the MSI. MSI is just not built for downloading additional data and running arbitrary application logic, it is meant for installing files and changing system settings. Even WiX uses custom bootstraping applications for things that go beyond that. One could build on top of the Windows Installer infrastructure to install toolchains, but that would require to repackage every installable package as Windows Installer modules, and it would still require an additional GUI for managing everything (because there seems to be no way to dynamically update the features/modules that are available in an installer) and the Windows version would be basically totally different from all other platforms, which constitutes a heavy maintenance burden.

One could write such a GUI, but not using WiX/MSI ... however, I think a graphical user interface for rustup should rather be part of an IDE. So users who don't want to use these graphical tools can still use the command line as on any other platform, and IDEs can provide toolchain management by wrapping rustup and showing whatever GUI fits their needs. Users who don't use an IDE probably are fine without a GUI, and that usecase should be consistent with other platforms. It would be nice if rustup could make it easy for other applications to wrap it (especially the download progress updates are probably a bit hard to deal with if there's no alternate "machine readable" output format).

[dataf3l]

NSIS Anyone?

[brson]

@Boddlnagg ok, thanks for the explanation. If it's not appropriate to have a component within the MSI then we shouldn't.

As a starting point just getting a GUI replacement for rustup-init is great. Though rustup-init does allow component selection. Would you see us not having any kind of of screen in the MSI that allows for selecting components?

I still feel like for the best experience there should be a GUI that allows one to do component selection at install / update time. Take the VS installer for example. That's the kind of experience I think windows users expect.

I do understand the notion that IDES should handle rustup installation, and agree. I hope we get to the point in Rust where we can say "Install VS code, install the Rust plugin", and the plugin deals with rustup however is most appropriate for VS code. But there are a lot of IDEs, and they're not all going to reach that level of integration.

[Boddlnagg]

It is definitely possible to have a screen to select components, but I think (at least I didn't find a way to do it – though I would not consider myself an expert with MSI) they need to be hardcoded into the MSI, so can't be updated on the fly when the installer is run. This is what I meant when I said that dynamic updates to features are not possible. This makes it unsuitable to e.g. have every single Rust nightly release as selectable MSI component.

[Boddlnagg]

@brson What exactly is the definition of a "component" in this context? How dynamic is the set of selectable components?

[workingjubilee]

@rustbot label: +O-windows

[Keavon]

Rust is very developer-friendly with its tooling and most areas of the experience. But having to use a console-based installer is really not a great first impression. It also doesn't make the MSVC requirement very clear and it's easy to skip by accident. A GUI could help clarify that. This would bring Rust's installation process more on par with other languages and dev tooling I'm used to. I can't think of any other programming languages that require a command line installation process.