Create Windows Python virtualenv with a specific version of Python

I have multiple versions of Python. I need to create a virtualenv for my project and make sure that it's using Python 2.7.

I've tried to accomplish this with the combination of this guide for virtualenv on Windows and this SO post on virtualenv with a specific kind of Python.

Unfortunately it's not working, which is probably because the latter resource was written by someone using Linux.

Here's what I did:

C:\Python27\Scripts>pip install virtualenv You are using pip version
6.0.6, however version 9.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Collecting virtualenv   Downloading virtualenv-15.1.0-py2.py3-none-any.whl (1.8MB)
    100% |################################| 1.8MB 3.7MB/s eta 0:00:01 Installing collected packages: virtualenv

Successfully installed virtualenv-15.1.0

C:\Python27\Scripts>pip install virtualenvwrapper-win You are using pip version 6.0.6, however version 9.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Collecting virtualenvwrapper-win   Downloading virtualenvwrapper-win-1.2.1.zip Requirement already satisfied (use
--upgrade to upgrade): virtualenv in c:\python27\lib\site-packages (from virtualenvwrapper
-win) Installing collected packages: virtualenvwrapper-win   Running setup.py install for virtualenvwrapper-win Successfully installed virtualenvwrapper-win-1.2.1

C:\Python27\Scripts>mkvirtualenv c:\users\hackr\Desktop\P27_D19  --python=C:\Python27\python.exe

'python.exe' is not recognized as an internal or external command, operable program or batch file.
'virtualenv.exe' is not recognized as an internal or external command, operable program or batch file.

Update: I just got this to work using plain virtualenv instead of the recommended mkvirtualenv command, which I assume is part of the wrapper they had me install. If someone would like to help me understand what happened and if there are any downfalls of not using the wrapper, that would be a good way to write up the answer.

Solution

If having multiple Python versions (or more: multiple instances of the same version) installed, it's best to always specify full paths (to be sure) and not rely on environment variables (at least that's how I do it - check [SO]: How to install a package for a specific Python version on Windows 10? (@CristiFati's answer)):

pip install virtualenv: I do it like : "C:\Install\x64\Python\3.5.3\python.exe" -m pip install virtualenv (don't mind the paths) to control the Python installation (same thing for VirtualEnvWrapper).
From now, I'll be referring to Python 3.5 installation path (C:\Install\x64\Python\3.5.3) as (like it was an Nix environment variable): ${PY35_PATH}.

I don't have MkVirtualEnv (mkvirtualenv tool) in my "${PY35_PATH}\Scripts" folder, but (this is an example that I "crafted" now):

"${PY35_PATH}\Scripts\virtualenv.exe" -p "c:\Install\x64\Python\2.7.13\python.exe" "c:\venvs\py2713"
- Or "${PY35_PATH}\python.exe" -m virtualenv -p "c:\Install\x64\Python\2.7.13\python.exe" "c:\venvs\py2713"

From then on:

"c:\venvs\py2713\Scripts\activate.bat"
python ......

I know, it's kind of annoying to specify all those funky paths (on Nix is soooo much easier), but at least it's safe. Anyway, after setting up the virtual environments, you can adjust your environment (%PATH%), so you don't have to specify full paths.

I noticed your comment while writing, and I must say that PyCharm (Professional Edition) is an excellent tool to work with Django (as a matter of fact with Python in general). If on the other hand, you go for Community Edition it's not quite so great (as expected). [SO]: Run / Debug a Django application's UnitTests from the mouse right click context menu in PyCharm Community Edition? is one of the painful issues that I had to deal with.

Update #0

Just now I installed VirtualEnvWrapper-Win: "${PY35_PATH}\python.exe" -m pip install virtualenvwrapper-win. Running MkVirtualEnv, either by its full path or by adding its parent folder in %PATH% (mkvirtualenv a), yielded the same error:

'python.exe' is not recognized as an internal or external command, operable program or batch file.

but it created the VEnv (under %USERPROFILE%\Envs). So the error is benign. Anyway it can be fixed by either:

Setting %PYTHONHOME%
Adding the path to python.exe in %PATH%

An additional step that I did, was setting %WORKON_HOME% to the folder where I want my VEnvs to be located. Note that the environment variables must be persisted (since I only did this for testing purposes I only set them in the Cmd console that I used for this task), otherwise they'll have to be set every time you need to use these tools.

After that, workon, lsvirtualenv worked like a charm (well, not as great as in Nix, but close enough).

Note (about MkVirtualEnv v1.2.1): It will use the default python.exe (see above), as a base for the new VEnv, it's not as flexible as virtualenv.exe (which accepts the -p / --python argument).