The internet makes it hard to discern tone...
I've been very interested in this topic since finding out about the WSL thing with VirtualEnv. I actually spent a lot of time yesterday (more than I would like to admit) trying to understand the WSL component to VirtualEnv. Even for me, it did seem odd to need that installed considering what it actually does. What exact role does WSL play in it? Windows does have it's own version and set of APIs that do the same thing as VirtualEnv and for Python not to utilize those is a bit surprising considering the Python interpreter does use a lot of Windows-native API's when processing code interpretation.
Here's what I figured out.
WSL has two versions. Version 2 is basically a VM running Linux (I am not blocking this version). The only difference between it and Hyper-V is the fact that the OS operates it without the need for user intervention during setup as is required with Hyper-V. WSLv2 uses Hyper-V directly so those components are required to function. WSL version 1 is an isolated container that runs a specialized driver that converts all Linux kernel calls to Windows kernel calls. calls are then executed on the Windows kernel. There is a special isolation layer involved which separates the Windows and Linux execution environments.
Windows also has a built-in isolation component called AppContainer which isolates an application in many ways similar to VirtualEnv. The only difference (other than API and code) between AppContainer and VirtualEnv is that AppContainer has more isolation capabilities then VirtualEnv. From what I can tell, VirtualEnv does Process isolation (which allows multiple versions of Python to be installed and running at the same time) and File Isolation (to separate dependencies and have multiple versions of dependencies running at once for different things). AppContainer does the same thing, but also adds Window Isolation (application interface), Network Isolation, Device Isolation (device resources and sensors) and Credential isolation. You can activate all of these isolation features for an application at the same time, or pick and choose which you want enabled and disabled for your application.
So it surprised me that Python didn't use this for their Windows version of VirtualEnv until I did more digging into AppContainers and the requirements for File and Process isolation. It all has to be native code (binary). Since Python is an interpreted language, AppContainers is not supported. It cannot be used with interpreters because of how it functions.
So this leaves Python with only one other option, WSL. Now I get to the part where I say, this gets a little confusing because, Python does install WSLv1 while installing itself (using pip or their own manual install process which you can find on the VirtualEnv web site) but they don't install the entire WSLv1 subsystem. WSLv1 is broken down into several components. It seems to *install* and I use that loosely, 4 components of the WSLv1 subsystem. However, when running Evennia in it, it only activates 3 of the 4 WSL components. Perhaps the 4th is for something that Evennia doesn't do directly but other Python programs do. Not sure.
This leads me to the question of, why can't VirtualEnv run natively without WSL external help. So, I did a little more digging into how VirtualEnv operates. The best I can come up with is that in Linux, applications can directly control how isolation works. In Windows, the OS has to do it for the application. This means Python does not have direct control over how it works. Additionally, the way Windows isolation works, it wouldn't allow multiple dependencies to operate in isolation while allowing them to be accessible externally to other python applications, not without AppContainer and not without native binaries. WSLv1 allows for python to bypass this since WSLv1 is a trusted component of windows. (this is also why I block it.)
This was a very interesting rabbit hole to fall into.
I have oversimplified a few explanations for reduced brevity of this post.