Investigation: Installing a WSL extension out of the box on Windows

[joaomoreno]

We're looking for a way to help Windows users install WSL and the Remote WSL extension.

We first investigated if it makes sense to bundle the Remote-WSL extension with VSCode, but ended up not doing that. Instead we added a smaller remote-wsl-recommended extension. That work was done in microsoft/vscode-remote-release#4255.

• Create a build with a extension as builtin only for Windows @joaomoreno

No longer needed / relevant:

• Allow updated out-of-band @joaomoreno
• Make sure the Remote extension pack can still be installed/uninstalled @joaomoreno
• The remote explorer shouldn't show up if WSL isn't installed at all @aeschli

[bamurtaugh]

Some thoughts:

• Do we indicate to users they are getting Remote-WSL as they're installing VS Code?
• Do all Windows installs of VS Code get Remote-WSL?

More specifically:

Do we want to make sure users have WSL?

• Do we include Remote-WSL with any Windows install of VS Code, no matter what the user has installed/configured on their machine (including if they don't have WSL)?
  • Do we indicate to users in any way that they're getting Remote-WSL?
• Or, do we just include Remote-WSL if the user has WSL on their machine?

Checkbox, warning, opt-in/out

• Do we include a checkbox in the VS Code installer where users can opt-in to installing Remote-WSL, and the box is already checked no matter what?
• Or, do we include a checkbox where users can opt-in to installing Remote-WSL, and the box is only checked if they have WSL installed on their machine/they meet some other condition?
• Or, do we include a checkbox where users can opt-in to installing Remote-WSL, and the box is not checked by default?

I was thinking we'd want to include Remote-WSL if the user has WSL installed on their machine, and show a checkbox where it's checked automatically so that users are aware Remote-WSL is being added.

[joaomoreno]

My preference: a dedicated page during the setup wizard which would contain a short explanation of WSL and a checkbox which
the user could control, checked by default, independently of the existence of WSL in the system. This is because, and @aeschli correct me if I'm wrong, the Remote WSL extension can guide users to install WSL if missing.

[aeschli]

Yes, sounds good to me that the extension will do the guiding on how to install. Currently the install steps are non trivial, but in near future there's a setup wizard provided by wsl. It's easier to have the extension contain that logic.

But I think what would be really good if the install wizard can a link to more information. That way you can keep the description in the setup wizard brief.

[lszomoru]

Another aspect that needs to be factored in is that WSL is not supported on all version of Windows that are supported by VS Code. Whether we go with a page in setup, or bundling, we should only install the extension if the OS would support WSL2 (Windows 10 1903 or later).

Do we have guidance on what is the bar for an extension to be included as a bundled extension?

[joaomoreno]

Another aspect that needs to be factored in is that WSL is not supported on all version of Windows that are supported by VS Code. Whether we go with a page in setup, or bundling, we should only install the extension if the OS would support WSL2 (Windows 10 1903 or later).

👌

---

Implementation-wise I think it would be best if the extension was actually bundled with the setup as a built-in extension. The question remains: will further Marketplace publishes of this extension trigger VS Code to install newer versions of the extension in the user's extensions folder and prefer those newer versions? That is the ideal scenario. @sandy081 remind me if this is what's currently implemented or not.

[lszomoru]

As WSL becomes an important element of the developer story on Windows, I would like to propose that we bundle the WSL extension as a built-in extension for all versions of Windows that support WSL2 (Windows 10 1903 or later), without making any changes to the setup wizard.

While this change will get the extension installed on new machines that install VS Code, we should also consider installing the WSL extension as part of the VS Code update process so that the extension gets installed on machines that support WSL2 and already have VS Code installed.

@aeschli, does the WSL extension show a notification on activation if you have WSL installed? What about if WSL is not installed? Are we planning any changes related to these notifications? I am asking since it might cause some confusion if we install the extension as part of the update, and after restart suddenly the user would be presented with a WSL related notification.

[aeschli]

There are some drawbacks with always bundling the Remote-WSL extension:

• the remote indicator (status bar, lower left corner) would always show (it shows when there is an extension that makes contributions to it). Some users might not like that. Also, in the next release of Remote-WSL we are showing new a new 'Open in WSL' button and menu points that will be in the way of users that don't want WSL.
• we lose a chance to promote WSL. Right now it's the recommendation "The extension Remote-WSL is recommended as you have WSL installed' which offers, IMO, a quite a smooth and seemingly smart way of promoting our extension and remote story. Having the option in the wizard would give us a nice possibility to promote WSL. We could even decide to not enable the install by default, but the link to WSL will get people interested.

IMO, enabling new capabilities is always a nicer user experience that getting everything but then having to learn how to disable features as you don't need.

To your question. When the extension is installed, all commands show up regardless if WSL is installed. When invoked, we bring a dialog that contains a how-to-install link.

[sandy081]

@joaomoreno Built in extensions cannot be updated from Marketplace currently. #68410

[joaomoreno]

@aeschli Could the Remote WSL extension be modified to address your bullet points? The green indicator could be omitted until WSL is actually installed, for example.

[IAmHopp]

Sorry guys, what's the thinking behind this? I can't see anywhere in this thread an actual explanation of why everyone needs this extension installed.

I mean, there's even talk here of installing the extension to existing installations of VS Code that don't contain it. Why are we doing that exactly? Wouldn't the user install it if necessary?

As a user, I'm not seeing the need for this, honestly.

[Studio384]

I agree with @IAmHopp; why? Is WSL2 actually becoming an "important element of the developer story on Windows" or is that just bias from a team that uses it a lot? Can we include Docker, ESLint and Material Icon Theme in VSCode by default as well, as these extensions have a larger userbase than Remote WSL, some far larger.

Why is this a discussion on the "how" instead of first asking "should" and "why"?

Add an optional opt-in to the first run experience if WSL is already present on the system; sure, why not. But pushing it on all users just because? No. Then where is the line being drawn as to when an extension should be built-in or not?

[aeschli]

We came up with a different approach to help users to learn and familiarize with WSL and the Remote-WSL extension: microsoft/vscode-remote-release#4255 adds a remote-wsl-recommender extension that allows us to do that.

The remote-wsl extension stays a separate extension and users can choose to install or uninstall it as with all other extensions.

The work done by @joaomoreno done for this issue was essential for microsoft/vscode-remote-release#4255. I therefore renamed the description to represent only the work done by @joaomoreno