I was forced to use WSL on Windows 10 to install the Python library Cartopy on my Windows machine correctly. It is way easier in a Linux-distribution, so I chose Ubuntu 20.04 WSL2.
As a consequence, I created a virtual Python environment via WSL in my project folder via python -m venv linux-venv
.
The problem is now that all binaries/executables were compiled for the WSL-distribution and are thus not selectable from VS Code started from within Windows 10.
Consequently, I installed VS Code on WSL and started it from there.
My hope was that I can then manually select the right interpreter path linux-venv/bin/python
from my project's root directory.
Unfortunately, it does not work either, even though I'm doing this from VS Code running on WSL:
Clicking on my desired interpreter linux-venv/bin/python
, the following error message is displayed:
If I try to "browse to my desired executable" instead, they are not displayed since solely ".exe" - file extensions are allowed:
Next, I can solely browse ".exe" - files, wherefore I cannot select the UNIX-compiled executables.
Conclusion:
It does not seem possible at the moment to select a UNIX-compiled interpreter in VS Code properly on a Windows 10 - machine, not even using WSL.
Since the aforementioned Python library Cartopy solely works well on UNIX-systems, I need to install my virtual environment from WSL.
In order to continue with my project, I would need to be able to select the UNIX-compiled interpreter, but I cannot.
Problem Analysis:
I figured out what the actual problems were in order to make it work according to the kindly shared WSL-docs by @Philippe and @JialeDu:
Consequently, starting VS-Code from within WSL or clicking on the "remote button" provided by the WSL-extension was fine, but when I opened the project it was still located on the Windows-C-drive. This silently broke the remote connection to WSL and left me working in VS-Code in Windows just like normally.
Obviously, this made it impossible to search for UNIX-executables and even select them, since I was effectively working on Windows, not on Linux (WSL).
Solution:
C:\Users\username\Projects\project_name
to the actual Ubuntu-WSL-System in /home/username/projects/project_name
.python3 -m venv linux-venv
.This time, it worked since I was effectively working on a true Linux environment/distribution with all packages and binaries installed within WSL.
Not only did I have to migrate the entire project on the WSL-distribution's directory tree, but I also had to reinstall the requirements and binaries of the virtual environments from there.