microsoft / microsoft/WSL

Allow `wsl --install` to create multiple installations of the same distribution on a computer

Open
#8,377 0 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
C++
Stars
33.7k
Forks
1.8k
Avg merge
3d 17h
Merged PRs (30d)
116

Description

Is your feature request related to a problem? Please describe.
The current paradigm for creating a second (or third...) installation of a WSL distribution on a given computer is more difficult and less fluid than the process for creating the first one. I believe we should mitigate this interest by having the wsl executable hide these differences.

Describe the solution you'd like
I would like wsl --install --distribution XYZ to be able to succeed, even if distribution XYZ already has an installation on the computer in use. Ideally, I would like to see a --name parameter as well, so that we can choose the name of the installation. This would be helpful for scripting the setup of a new installation.

Describe alternatives you've considered
I have considered, and used, the wsl --export/import process. I explain below why I think having this functionality available in wsl --install is an improvement. I am not suggesting that we also remove wsl --export/import.

Additional context
Being able to install multiple installations of a Linux distribution with wsl --install has the following advantages, all of which hold real value for the community:

  • It makes it trivial to create a "clean" installation of a distribution, even if you already have another installation of that distribution. This is not an entirely uncommon use case. Suppose a developer has an installation of (for example) Debian, and it has been patched and had several software packages installed and dotfile-style modifications applied. Suppose further that for testing purposes, they want to create a "clean" installation of Debian, and still keep the installation they have, and also keep the distribution name the same for the current installation. I think that the way to do this currently is something like this:
mkdir c:/wsl_distro_tarballs
mkdir c:/wsl_distro_installs
wsl --shutdown # or wsl --terminate debian
wsl --export debian c:/wsl_distro_tarballs/debian_original.tgz
wsl --unregister debian
wsl --install --distribution debian
wsl --shutdown # or wsl --terminate debian
wsl --export debian c:/wsl_distro_tarballs/debian_clean.tgz
wsl --unregister debian
wsl --import Debian c:/wsl_distro_installs/debian c:/wsl_distro_tarballs/debian_original.tgz
wsl --import Debian-Clean c:/wsl_distro_installs/debian_clean c:/wsl_distro_tarballs/debian_clean.tgz

This is much simpler, and much more like the experience the developer had when creating the first Debian installation. Presumably, it also wouldn't require shutting down the installation that was already in place:

wsl --install debian --name Debian-Clean

If there's a better way to do this, it's not obvious enough, at least not to me. The fact that there are now two exported tarballs containing complete Linux distributions on this developer's workstation is a problem, but this is really just collateral damage compared to the rest of the unneeded pain points introduced by this process.

  • It eliminates the need for every developer to export and store an extra tarball of the Linux distribution they want to clone. This process is not required for the initial installation of a distribution. Why should a second installation be different? Allowing wsl --install to create the second installation makes the developer experience more consistent and result in less space used on the developer workstations, assuming they save the tarballs for future use.
  • It eliminates the risk of cloning an old tarball that is far behind on security patches. Granted, we should patch a new installation regardless, but it's better to start with the currently-supported distribution. Allowing wsl --install to create the second installation makes patching a uniform task that can be debugged uniformly among all developers that follow the "standard path."
  • As an extension to the prior point, it saves confusion in discussions. When we encourage cloning as the only way to make a second installation of a distribution, suddenly the following sentence becomes full of ambiguity: "I just created a second installation of WSL Debian, and I'm having a problem." That sentence is full of ambiguity because currently, we have no idea what the new installation of Debian has in it. If wsl --install had created the new installation, then we would know exactly what the new installation contained, and engaging this person to help fix their problem would result in a solution that would help others in the same circumstance.

I know this has been suggested before but has any additional thought been given to moving forward with allowing wsl --install to create multiple installations of the same distribution?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the wsl --install entry point and compare its existing --distribution behavior with the --export/--import workflow described here. Determine how repeated distributions and the proposed --name parameter should be represented and validated. Done means wsl --install can create another installation of an already-installed distribution without the export/import workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
cli, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.