How to Run Multiple Python Versions on Windows

How to run multiple Python versions on Windows

Running a different copy of Python is as easy as starting the correct executable. You mention that you've started a python instance, from the command line, by simply typing python.

What this does under Windows, is to trawl the %PATH% environment variable, checking for an executable, either batch file (.bat), command file (.cmd) or some other executable to run (this is controlled by the PATHEXT environment variable), that matches the name given. When it finds the correct file to run the file is being run.

Now, if you've installed two python versions 2.5 and 2.6, the path will have both of their directories in it, something like PATH=c:\python\2.5;c:\python\2.6 but Windows will stop examining the path when it finds a match.

What you really need to do is to explicitly call one or both of the applications, such as c:\python\2.5\python.exe or c:\python\2.6\python.exe.

The other alternative is to create a shortcut to the respective python.exe calling one of them python25 and the other python26; you can then simply run python25 on your command line.

How to install multiple versions of Python in Windows?

Your questions depend a bit on "all the other software". For example, as @leiyang indicated, the answer will be different if you use conda vs just pip on vanilla CPython (the standard Windows Python).

I'm also going to assume you're actually on Windows, because on Linux I would recommend looking at pyenv. There is a pyenv-win, which may be worth looking into, but I don't use it myself because it doesn't play as nice if you also want (mini)conda environments.

1. (a) How do I install multiple Python versions?

Simply download the various installers and install them in sensible locations. E.g. "C:\Program Files\Python39" for Python 3.9, or some other location where you're allowed to install software.

Don't have Python add itself to the PATH though, since that'll only find the last version to do so and can really confuse things.

Also, you probably want to use virtual environments consistently, as this ties a specific project very clearly to a specific Python version, avoiding future confusion or problems.

1. (b) "3.8.1, 3.8.2 till 3.8.13" which should I pick?

Always pick the latest 3.x.y, so if there's a 3.8.13 for Windows, but no 3.8.14, pick that. Check if the version is actually available for your operating system, sometimes there are later versions for one OS, but not for another.

The reason is that between a verion like 3.6 and 3.7, there may be major changes that change how Python works. Generally, there will be backwards compatibility, but some changes may break how some of your packages work. However, when going up a minor version, there won't be any such breaking changes, just fixes and additions that don't get in the way of what was already there. A change from 2.x to 3.x only happens if the language itself goes through a major change, and rarely happens (and perhaps never will again, depending on who you ask).

An exception to the "no minor version change problems" is of course if you run some script that very specifically relies on something that was broken in 3.8.6, but no fixed in 3.8.7+ (as an example). However, that's very bad coding, to rely on what's broken and not fixing it later, so only go along with that if you have no other recourse. Otherwise, just the latest minor version of any version you're after.

Also: make sure you pick the correct architecture. If there's no specific requirement, just pick 64-bit, but if your script needs to interact with other installed software at the binary level, it may require you to install 32-bit Python (and 32-bit packages as well). If you have no such requirement, 64-bit allows more memory access and has some other benefits on modern computers.

2. Why does Python have such heavy dependency on the exact versions of libraries and packages etc?

It's not just Python, this is true for many languages. It's just more visible to the end user for Python, because you run it as an interpreted language. It's only compiled at the very last moment, on the computer it's running on.

This has the advantage that the code can run on a variety of computers and operating systems, but the downside that you need the right environment where you're running it. For people who code in languages like C++, they have to deal with this problem when they're coding, but target a much smaller number of environments (although there's still runtimes to contend with, and DirectX versions, etc.). Other languages just roll everything up into the program that's being distributed, while a Python script by itself can be tiny. It's a design choice.

There are a lot of tools to help you automate the process though and well-written packages will make the process quite painless. If you feel Python is very shakey when it comes to this, that's probable to blame on the packages or scripts you're using, not really the language. The only fault of the language is that it makes it very easy for developers to make such a mess for you and make your life hard with getting specific requirements.

Look for alternatives, but if you can't avoid using a specific script or package, once you figure out how to install or use it, document it or better yet, automate it so you don't have to think about it again.

3. Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.

Not all of them, but quite a few of them. However, you still need the original installation to be present on the system. Also, you can't pick up a virtual environment and put it somewhere else, not even on the same PC without some careful changes (often better to just recreate it).

You're right that this is a bit wasteful - but this is a difficult choice.

Either Python would be even more complicated, having to manage many different version of packages in a single environment (Java developers will be able to tell you war stories about this, with their dependency management - or wax lyrically about it, once they get it themselves).

Or you get what we have: a bit wasteful, but in the end diskspace is a lot cheaper than your time. And unlike your time, diskspace is almost infinitely expandable.

You can share virtual environments between very similar projects though, but especially if you get your code from someone else, it's best to not have to worry and just give up a few dozen MB for the project. On the upside: you can just delete a virtual environment directory and that pretty much gets rid of the whole things. Some applications like PyCharm may remember that it was once there, but other than that, that's the virtual environment gone.

Two versions of python in one computer

The preferred way to use python virtual environments now is venv.

You can install any number of python versions on your windows, though please also install the py launcher that it comes with. This makes it easy to launch whichever python version you want through the commandline, with no need to rely on PATH nonsense.

If you've the py launcher you can simply launch your desired python version using-

py -3.6-64

The above will launch the 64 bit version of python 3.6 (if installed).

Now, you'll also want to use a virtual env and point pycharm to the venv. To make a venv, go to your project directory (preferably) and do-

> py -3.6-64 -m venv name_of_venv

This will make a venv named of name_of_venv in your project directory and the python version will be 3.6 64 bit.

Now whenever you need to do any python commands, you no longer need to do py -version, you can just do python and even use pip - BUT before that, you need to activate the venv

> & '.\name_of_venv\Scripts\Activate.ps1'

Now you can do normal python operations as long within this venv and it'll all target 3.6 64 bit (or any other version you choose to build the venv with).

To deactivate (though you don't really have to) - you can just type deactivate in the terminal.

Pycharm can be configured with this venv as simply as just pointing to it. You simply have to go to Add python interpreter and choose Virtualenv Environment

How to manage multiple Python versions in Windows 10 to use with Python tox?

tox has quite some logic implemented to find installed Python interpreters.

While the documentation lacks some details (maybe you want to create an issue?), we can still have a look a the source code:

@tox.hookimpl
def tox_get_python_executable(envconfig):
    spec, path = base_discover(envconfig)
    if path is not None:
        return path
    # second check if the py.exe has it (only for non path specs)
    if spec.path is None:
        py_exe = locate_via_pep514(spec)
        if py_exe is not None:
            return py_exe

    # third check if the literal base python is on PATH
    candidates = [envconfig.basepython]
    # fourth check if the name is on PATH
    if spec.name is not None and spec.name != envconfig.basepython:
        candidates.append(spec.name)
    # or check known locations
    if spec.major is not None and spec.minor is not None:
        if spec.name == "python":
            # The standard names are in predictable places.
            candidates.append(r"c:\python{}{}\python.exe".format(spec.major, spec.minor))
    return check_with_path(candidates, spec)

As you can see, there are five ways to determine the available Python interpreters on a Windows system.

Especially the second one looks promising -it is using the already mentioned Python launcher for Windows, also see https://www.python.org/dev/peps/pep-0514/

As far as I understand it, you just need to install your Python interpreters, and they will be automatically discoverable.

tox is definitely a very good way to test Python applications against multiple interpreters, both locally and in CI.

P.S.: Yes, it works!!

I just rdp'ed into a Windows box, installed Python 3.8 and Python 3.9 - just clicked through the default installer, and created the following tox.ini

[tox]
envlist = py38, py39

[testenv]
commands = python -c "print('hello')"
skip_install = true

Both interpreters were detected and both environments got executed.

(venv) C:\Users\jugmac00\Projects\stackoverflow>tox
py38 create: C:\Users\jugmac00\Projects\stackoverflow\.tox\py38
py38 run-test-pre: PYTHONHASHSEED='296'
py38 run-test: commands[0] | python -c 'print('"'"'hello'"'"')'
hello
py39 create: C:\Users\jugmac00\Projects\stackoverflow\.tox\py39
py39 run-test-pre: PYTHONHASHSEED='296'
py39 run-test: commands[0] | python -c 'print('"'"'hello'"'"')'
hello
_______________________________________________________ summary _______________________________________________________
  py38: commands succeeded
  py39: commands succeeded
  congratulations :)

(venv) C:\Users\jugmac00\Projects\stackoverflow>

how to run scripts with multiple python versions installed?

Note: For Windows use the new Windows Python launcher (available with Python 3.3 and downloadable here for earlier releases) which recognizes Unix shell shebangs. You can read about it here.

Most Linux distributions will create python2 and python3 aliases for the installed Python 2.x and Python 3.x interpreter (if not you can just create the symbolic links yourself anywhere on your $PATH, the env command will take care of finding them), so you should just need to set the appropriate interpreter as the first line of your script:

#!/usr/bin/env python2

or

#!/usr/bin/env python3

This will direct the shell to use the appropriate interpreter, if you set the script files to be executable and just invoke them directly on the shell. E.g.:

$ chmod +x script.py
$ ./script.py

How to run different python versions in cmd

Python 3.3 introduces Python Launcher for Windows that is installed into c:\Windows\ as py.exe and pyw.exe by the installer. The installer also creates associations with .py and .pyw. Then add #!python3 or #!python2 as the first lline. No need to add anything to the PATH environment variable.

Update: Just install Python 3.3 from the official python.org/download. It will add also the launcher. Then add the first line to your script that has the .py extension. Then you can launch the script by simply typing the scriptname.py on the cmd line, od more explicitly by py scriptname.py, and also by double clicking on the scipt icon.

The py.exe looks for C:\PythonXX\python.exe where XX is related to the installed versions of Python at the computer. Say, you have Python 2.7.6 installed into C:\Python27, and Python 3.3.3 installed into C:\Python33. The first line in the script will be used by the Python launcher to choose one of the installed versions. The default (i.e. without telling the version explicitly) is to use the highest version of Python 2 that is available on the computer.

---

Related Topics