pythonpython-3.6python-3.7python-venvvirtual-environment

Python3.7 venv does not Create Virtual Environment Directory


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:

enter image description here

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


Solution

  • 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):

    When all the above checks pass, you should be able to create and use a (VEnv created) virtual environment.

    Update #0

    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:

    img00

    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 and python3 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:

    Might be related: