In general, your problem isn't in trying to specify a different Python version, but in trying to use a Python executable for a different operating system. When in WSL, you are essentially running Linux binaries and libraries, but you are attempting to have the Linux Python create a virtual environment using the Windows Python executable.
There are a number of reasons why this is a bad idea, and the error you are getting demonstrates one of them:
- The Linux Python interpreter doesn't understand Windows paths, and vice-versa.
In other words, python3, the Linux Python interpreter, can't parse the path D:\Python_Versions\python.exe.
WSL provides a nice "translation" utility wslpath that can convert between Linux paths and Windows paths. For instance:
/mnt/d/Python_Versions/python.exe <-> D:\Python_Versions\python.exe/home/user/username/src/python_project <-> \\wsl$\<distroname>\home\user\username\src\python_project
However, that's not going to help you with this particular problem. You would need the Linux Python to convert all paths like this, which it isn't going to do.
In addition, while WSL can run Windows executables (such as python.exe), those executables won't be able to access Linux libraries and processes.
And yet another reason this won't work -- Windows Python can't operate on the pseudo-network share drive that otherwise allows Windows processes to access WSL/Linux files. For instance, if you are in PowerShell:
cd $env:USERPROFILE\Documents
mkdir src\python
cd src\python
python -m venv new_virtualenv
# Works
But (also from PowerShell):
cd \\$wsl\<distroname>\home\<username>\
mkdir src\python
cd src\python
python -m venv new_virtualenv
# Error: [WinError 1] Incorrect function
Assuming that Windows Python is in your Windows path, you can, on the other hand, in WSL:
cd /mnt/c/Users/<username>/Documents
mkdir src/python
cd src/python
python.exe -m venv new_virtualenv
However, you can't activate the virtual environment since Windows Python doesn't create activation scripts for Linux. It does create a Bash script, but it's for Git Bash, and if you examine it (./Scripts/activate in that venv directory), you'll see it still uses Windows paths.
There's really just no way around it:
- Use the Linux Python binaries and modules when developing in Linux.
- Use the Windows Python binaries and modules when developing in Windows.
Conversely:
- When in a Windows environment, use the Windows Python binaries and modules.
- When in a Linux/WSL environment, use the Linux Python binaries and modules.
Side note: As you might realize by now, the --python flag for virtualenv is designed to allow you to specify a different Python version that matches the OS architecture. In other words, if you are on Ubuntu/WSL (which I don't believe you are, given your pip example):
sudo apt install python2
sudo apt install python3-pip
pip install virtualenv
python -m virtualenv --python=/usr/bin/python2 new_virtualenv
cd new_virtualenv
source bin/activate
python --version
# Will return Python 2.7.18
Update, addressing your additional comments:
Do you have any suggestions of how to cleanly install Python on Windows with different environments that use different Python versions (and preferably all access one Spyder installation), while NOT reverting back to something like conda or that sort?
Since Spyder is a Python app itself, it's going to have the same problem communicating "cross platform" that the Python virtualenv does. You can try to set your Windows Python executable as the WSL Spyder terminal, but it wouldn't actually be able to launch it since the Linux Spyder won't be able to communicate with the spyder-kernel module even if you install it in Windows.
And vice-versa.
I'm just not aware of (and couldn't find any, in my research) WSL <-> Windows interop features in Spyder.
You haven't explained your use-case for needing both Windows and Linux Python environments, but if you are going to use Spyder, and you really need both Windows and Linux Python binaries, then I'm fairly confident that you'll need to install Spyder twice -- Once in Windows and once in WSL/Linux.
And from what I understand, Conda is the best option for installing Spyder in Linux. You might also check out this Ask Ubuntu answer, but unfortunately that did not work for me.
Another option
If you aren't completely tied to Spyder, you might consider Visual Studio Code (the Windows version). It does have the ability to interact with both Windows and Linux/WSL Python interpreters.
After installing the "Remote - WSL" extension (from Microsoft), it can interact with the Linux Python by setting up a Linux server inside WSL. You can access Windows Python virtual environments (while in "Windows mode") and WSL virtual environments (while in "Remote - WSL" mode).
While I haven't tried these particular features myself, I am fairly certain, based on what I know of VSCode and WSL, that you can:
- Set up a Windows virtualenv with multiple Windows Python versions.
- Set up a Linux virtualenv with multiple Linux Python versions.
It has debugging support for both platforms, can support variable inspection (based on this answer), and probably much, much more through its rich extension library (currently 652 extensions returned from a search for "Python").
It's definitely worth checking out to see if it will meet your needs since it's one of the few Windows IDE's that can interoperate with WSL directly. My understanding is that Pycharm also has WSL integration, but I haven't explored that personally.
