Mark Mikofski added the comment:
Would you consider just handling activate for windows directly in the
lib/venv/__init__.py method "install_scripts(self, context, path)"
https://github.com/python/cpython/blob/4f98f465f14e7258c5b18a62c5aa114dbe1174d8/Lib/venv/__init__.py#L382
if not
Mo added the comment:
I had also tested with pathlib and posixpath and come to the same conclusion.
As suggested by you, I looked into `activate` determining path when run. I
believe this should do the trick (My bashfoo isn't strong, this is mostly from
https://stackoverflow.com/a/179231):
Steve Dower added the comment:
I agree this would be better, though it may not be that easy to do.
If you're running Windows Python from WSL, then your "bash style" path should
be "/mnt/c/some/path", not "/c/some/path". So the answer isn't as simple as
.replace('\\', '/').
I did some quick
Mo added the comment:
The issue comes as a result of abspath on line 59 of venv/__init__.py:
env_dir = os.path.abspath(env_dir)
This returns a Windows-style path, and os.path.abspath returning in this way is
*probably* correct, as the OS is Windows, despite trying to forget that by
New submission from Mo :
When creating a virtual environment on Windows from git-bash (using python -m
venv), VIRTUAL_ENV in the activate script is set using a windows style path
(C:\some\path) instead of the bash style (/c/some/path).
This means the system python and pip get used, despite
