I'm trying to create a virtual environment in windows using:
python3 -m venv <dir-name>
When I check the contents of the current directory in cmd after running the above command, I don't see the venv directory show up. The command doesn't throw any errors.
This person seems to have had the same problem: Python venv not creating virtual environment
But the accepted answer was to re-install python, which didn't work for me. Other answers suggest installing virtualenv instead, but as far as I know that is different from venv, which is recommended for python3.3+
Does anyone know how to solve this issue with venv? I've tried python 3.6 and 3.7
Edit: The problem seems to be that the location of python.exe set in PATH is not being used. It is instead using: C:\Users\GSI\AppData\Local\Microsoft\WindowsApps\python3.exe
. I'm not sure how to fix my environment variable. Is a restart required? I have quite a few things running but I can restart if it's necessary
Edit2: I was asked to post a screenshot of the output of the following commands. As you can see, there is no output when I run them with just "python3". When I run the commands with the full path where the exe is installed, I do get ouptut:
Edit 3: I found a helpful post here: https://superuser.com/questions/1437590/typing-python-on-windows-10-version-1903-command-prompt-opens-microsoft-stor
Apparently typing "python" into CMD when you don't have python installed/added to the PATH variable opens up the Microsoft store and creates a python.exe
file in C:\Users\GSI\AppData\Local\Microsoft\WindowsApps
. I'm guessing I tried executing python code when I first installed python but before I had added the PATH variable.
I followed the instructions in the post to remove the "Application Execution Aliases" for python.exe and python3.exe. That got rid of the exe files in WindowsApps (I wasn't able to manually delete them).
However, now when I type where python3
in CMD, I get:
INFO: Could not find files for the given pattern(s).
It seems like it's not picking up my PATH values. I tried restarting my computer but no luck
It should work, I tested it several times (e.g.: [SO]: PyWin32 (226) and virtual environments).
And yes, they are 2 different kinds of animals:
Example:
e:\Work\Dev\StackOverflow\q059885771> sopr.bat ### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ### [prompt]> set PY PYTHONPATH=e:\Work\Dev\Utils\current [prompt]> dir /b [prompt]> "c:\Install\pc064\Python\Python\03.07.06\python.exe" -c "import sys, venv;print(sys.version);print(venv)" 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] <module 'venv' from 'c:\\Install\\pc064\\Python\\Python\\03.07.06\\lib\\venv\\__init__.py'> [prompt]> "c:\Install\pc064\Python\Python\03.07.06\python.exe" -m venv usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] [--prompt PROMPT] ENV_DIR [ENV_DIR ...] venv: error: the following arguments are required: ENV_DIR [prompt]> time<nul The current time is: 21:51:57.12 Enter the new time: [prompt]> "c:\Install\pc064\Python\Python\03.07.06\python.exe" -m venv ".\venv_dir" [prompt]> echo %errorlevel% 0 [prompt]> time<nul The current time is: 21:52:10.54 Enter the new time: [prompt]> [prompt]> dir /b venv_dir [prompt]> "venv_dir\Scripts\python.exe" Python 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z [prompt]>
Notes (things to pay attention to):
Make sure that things are actually what you think they are: use full paths (like I did for the Python executable). To see what interpreter is invoked in your case, type where python3
in the console
Enclose paths in DblQuotes ("${SOME_PATH}"), as they might contain spaces (and the command interpreter will interpret the part after the SPACE as an argument to the one before)
Check the command return code
Check environment variables (e.g.: PYTHONPATH) that might impact the behavior
Of course, Python should be valid (no errors encountered during installation, no files deleted / modified afterwards, ...)
When all the above checks pass, you should be able to create and use a (VEnv created) virtual environment.
I took a look at the URL added in the question: [SuperUser]: Typing “python” on Windows 10 (version 1903) command prompt opens Microsoft store (mentioning @Update, @TusharGautam, @MattJecha, @Ramhound great answers, containing useful info and resources).
Apparently, it is because of the 2 App Installer related items from App execution aliases. Then I went further, and also installed Python 3.7 from Microsoft Store.
Both (App Installer and Python 3.7) place some items (including executables) in "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps". The funny thing is that they are 0 bytes sized, and they are neither shortcuts nor SymLinks. I tend to think they don't actually exist on the filesystem, but are some kind of "mock entries" that Win displays and acts as if they would be real (the same thing MS did when displaying the .NET assemblies (which are basically .dll files) as directories in Windows Explorer).
In the image below, I chose the 2 boxed items as examples:
When checking one, the other gets automatically unchecked, which makes sense as both point to the same "executable" (python3.exe).
[prompt]> :: Python3.7 (python3.exe - installed from Microsoft Store) checked [prompt]> dir "c:\Users\cfati\AppData\Local\Microsoft\WindowsApps\py*" Volume in drive C is SSD0-WIN Volume Serial Number is F2CE-FA29 Directory of c:\Users\cfati\AppData\Local\Microsoft\WindowsApps 20/01/24 12:32 0 python3.exe 20/01/24 12:12 <DIR> PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0 1 File(s) 0 bytes 1 Dir(s) 197,737,488,384 bytes free [prompt]> python3 -c "import sys, os;print(\"VER: {0:}\nEXE: {1:}\nCWD: {2:}\nPyPATH: {3:}\".format(sys.version, sys.executable, os.getcwd(), sys.path))" VER: 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 01:54:44) [MSC v.1916 64 bit (AMD64)] EXE: C:\Users\cfati\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\python.exe CWD: e:\Work\Dev\StackOverflow\q059885771 PyPATH: ['', 'e:\\Work\\Dev\\Utils\\current', 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1776.0_x64__qbz5n2kfra8p0\\python37.zip', 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1776.0_x64__qbz5n2kfra8p0\\DLLs', 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1776.0_x64__qbz5n2kfra8p0\\lib', 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1776.0_x64__qbz5n2kfra8p0', 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1776.0_x64__qbz5n2kfra8p0\\lib\\site-packages'] [prompt]> echo %errorlevel% 0 [prompt]> [prompt]> :: App Installer (python3.exe) checked [prompt]> dir "c:\Users\cfati\AppData\Local\Microsoft\WindowsApps\py*" Volume in drive C is SSD0-WIN Volume Serial Number is F2CE-FA29 Directory of c:\Users\cfati\AppData\Local\Microsoft\WindowsApps 20/01/24 12:35 0 python3.exe 20/01/24 12:12 <DIR> PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0 1 File(s) 0 bytes 1 Dir(s) 197,737,291,776 bytes free [prompt]> python3 -c "import sys, os;print(\"VER: {0:}\nEXE: {1:}\nCWD: {2:}\nPyPATH: {3:}\".format(sys.version, sys.executable, os.getcwd(), sys.path))" Access is denied. [prompt]> :: !!! "This app can't run on your PC" popped up !!! [prompt]> echo %errorlevel% 5
As a note, the executable ("C:\Users\cfati\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\python.exe") is also a "mock entry", the real one is actually located in "%ProgramFiles%\WindowsApps"
From [MS.DevBlogs]: Who put Python in the Windows 10 May 2019 Update? (emphasis is mine):
While Python continues to remain completely independent from the operating system, every install of Windows will include
python
andpython3
commands that take you directly to the Python store page.
So, there you go, python3 is not actually python3 (of course, applies to python as well). The funny thing is that in your case it "worked", while in mine it complained (ERROR_ACCESS_DENIED).
Conclusions:
I must insist on always using the full paths. That way you are not impacted by changes happening in the OS (well, your files might get deleted or corrupted, but then you'd have bigger issues)
Specifying the full path every time, would soon become very annoying, that's why the PATH environment variable could / should be used. Of course, this works fine (and significantly improves the experience) in probably 90+% of the cases, but there are some (for example when other installed apps / tools that also ship Python, add their dirs into PATH) where it can trigger funny results
Might be related: