[PoC] Rework WinGet guide to make use of configurations

[stevapple]

Rework the "Installation via Windows Package Manager" page to include interaction, and simplify all the steps to two winget configure commands. Closes #437.

Motivation:

Installing Swift on Windows requires multiple steps, and some of which cannot be handled (gracefully) by WinGet and other package managers. Luckily, we now have winget configure, a tool that can perform all the desired actions to the system with a single manifest.

Modifications:

• Replace the description "You may change the Visual Studio edition depending on your usage and team size." with a Visual Studio edition picker;
• Introduce a Windows SDK version picker to allow selecting the desired SDK version;
• Use winget configure in the guide, including:
  • Generating and serving configuration files on the website;
  • Allows automating the process of enabling developer mode on Windows.

Result:

The "Installation via Windows Package Manager" page is refreshed with new look (including VS and WinSDK picker) and to use winget configure. All the configuration files will be generated and served via the website.

[compnerd]

Conceptually this is pretty cool. I assume that we would select defaults for the user (community edition, latest SDK release) and let them alter it? I've not looked at the implementation so I do not feel like I can "approve" it, but I do like the idea.

[stevapple]

I assume that we would select defaults for the user (community edition, latest SDK release) and let them alter it?

Good idea! I've updated the default to VS Community and Windows 10.0.22621 SDK (the one shown in the screenshot), which is the default for VS 2022. The latest 10.0.26100 SDK is so new that VS has not officially adopted it yet.

[stevapple]

Note: We may need to hold off the change until WinGet v1.9+ has released a stable version, which either enables elevation by default or allows user to toggle it on. Older versions may not have the capability, and stable versions up to 1.8 doesn't support any experimental features.

[stevapple]

So far I've tested the configurations on:

• A machine with everything set up, where the commands basically do nothing and finish in seconds, as long as the corresponding configuration files are selected.
• A sandbox with nothing but WinGet, where the commands are capable of setting up all the required stuffs to make Swift available as soon as they're done.

Also proved that the 10.0.26100 SDK (not installed from VS) works with Swift, even on Windows 10.

[timsneath]

Curious: what happens when you run this command from an older version of WinGet (assuming the comment about 1.9 requirement is current)? Does it just fail?

The advantage of the current WinGet commands is that they work on almost any supported Windows machine.

[stevapple]

Curious: what happens when you run this command from an older version of WinGet (assuming the comment about 1.9 requirement is current)? Does it just fail?

Good question. And it depends on the version of WinGet installed:

• ..<"1.6.2631": it will fail because winget configure is not supported;
• "1.6.2631"..<"1.7.10514": it will fail because winget configure does not accept a URL;
• "1.7.10514"..<"1.8.1133-preview" or other stable versions before v1.9: "Enable Developer Mode" and "Install required VS workloads" will fail because it doesn’t support self-elevation in winget configure;
• "1.8.1133-preview"…: everything should work as expected.

The advantage of the current WinGet commands is that they work on almost any supported Windows machine.

Absolutely. But sadly they cannot cover installing VS and enabling Developer Mode in a friendly way…

[timsneath]

I'm excited for this improvement, but as you suggest above, I think we might want to wait at least until a version that supports it is more pervasively available.

I also worry a little about automating VS selection: some things we're going to want to consider:

• If a user has a version of VS2022 already, should we add workloads to it or install a second instance?
• If a user doesn't have VS2022, which edition should we install? Community is not licensed for commercial work, but Professional and Enterprise are paid licenses
• If a user has multiple VS channels installed (e.g. current and preview), which one should we install the workloads into?
• Is there a path where we install just the Build Tools SKU, rather than a full IDE? Should we make that the dependency and install a private channel of that?
• If a user already has a different version of Windows SDK installed, how should we handle that? Install our "preferred" version regardless of whether it's older or newer?

There's a lot of value in reducing the pain associated with installing on Windows, but if we're just masking some important decisions from the user on how they configure their workstation, we might want to err on the side of configurability.

[stevapple]

I also worry a little about automating VS selection: some things we're going to want to consider:

Try to explain one by one.

• If a user has a version of VS2022 already, should we add workloads to it or install a second instance?

We're not designating VS editions, nor automatically picking it up from the user's system, so it's up to the user's choice. If they select a different edition, then a new installation will be required.

• If a user doesn't have VS2022, which edition should we install? Community is not licensed for commercial work, but Professional and Enterprise are paid licenses

It's again up to the user. Swift works with all of them, so does the new picker UI.

• If a user has multiple VS channels installed (e.g. current and preview), which one should we install the workloads into?

This is an interesting quesion. It seems we're not considering the preview channel at the moment, so Release is hardcoded in the DSC file.

• Is there a path where we install just the Build Tools SKU, rather than a full IDE? Should we make that the dependency and install a private channel of that?

We've discussed about this before, see #361 (comment). With the picker UI we're including VS Build Tools as an option, which is not ever documented now.

• If a user already has a different version of Windows SDK installed, how should we handle that? Install our "preferred" version regardless of whether it's older or newer?

If you're speaking about the website, we're asking the user for the version they want. If the specified version is installed, it should not be reinstalled. The Swift toolchain will try to read SDK information from environment variables, and if not specified, use the newest version automatically.

[timsneath]

@stevapple I know it's been a little while, but with two more stable releases out the door that look like they support this (1.8.1791 and 1.9.25180), I think the timing is much better for this pull request. I see that .NET is now using it for their tutorial: https://dotnet.microsoft.com/en-us/learn/dotnet/hello-world-tutorial/install

What do you think?

Also flagging @compnerd and @shahmishal for their take.