Choosing between multiple Python installations (environments) on the same computer

Platform-agnostic information

Generally, every installation of Python has its own Python executable - i.e., python on Linux and Mac, or python.exe on Windows.^[1] So on the most basic level, the Python installation is chosen by simply choosing the Python executable.

You can always choose which Python to use if you know the path to the executable, by specifying that path directly.

However, this is often awkward, so the Python installers try to make it easier to choose the Python you want. This is done in platform-specific ways.

Linux and Mac

Python follows standard UNIX conventions by putting the actual python executable directly in /usr/bin (or another similar folder, such as /usr/local/bin, if you build from source and explicitly configure the installation that way)^[2]. Since that path is always in the PATH environment variable, simply using python at the command line will find a Python installation as long as there is one.^[3]

Of course, this naturally raises the question of what happens if we try to install more than one Python version. The simple answer: python is actually a symlink to one specific Python executable; the actual executables will be named according to the major and minor version number: thus, python27 for the now end-of-life and unsupported Python 2.7; python312 for the Python 3.12; etc. We can generally use these names directly on the command line, to choose the Python minor version, and thus the associated installation of Python.

Depending on the system configuration, there may also be python2 and/or python3 symlinks that will refer to a specific 2.x or 3.x installation respectively. (python2, if present, should normally mean a Python 2.7 installation, except on very old legacy systems.)

Windows

Windows generally organizes programs differently. It doesn't offer a separate folder for application-specific "libraries" (i.e. /usr/lib equivalent), and doesn't put system-wide installed executables side-by-side. Instead, generally each application gets its own sub-folder within C:\Program Files (or a similarly named location); and Python respects this convention.^[4] It's also probably more common on Windows systems to see Python installed "only for this user", which doesn't require administrator privileges.^[5]

Windows' organization scheme is problematic for command-line use of programs (including Python) because they can only be found directly in folders named in the PATH - subdirectories are not searched.

However, each installation provides separate executables (wrappers around the main DLL) following a similar naming scheme. So if one is willing to pollute the PATH in this way, the same sort of version-selection logic can be used on Windows as on Linux or Mac.

The Python Launcher for Windows

This is a separate application named py.exe which is installed directly in C:\Windows (so it's always on the PATH) and which chooses a Python installation for you. Installed versions of Python automatically register themselves with the launcher, and running py at the command line will choose an appropriate Python version - the most recent Python by default (even if it wasn't the most recently installed); or a version explicitly specified on the command line; or a version specified by the Python code itself.

Note that last part carefully: while Windows has no concept of a "shebang line" natively, the launcher emulates them for Python scripts.

The Python launcher for Windows offers quite a few customization options; please see the link in the section title for full documentation.

Patch versions, redundant installations etc.

The above schemes aren't designed to support more than one patch version of a given Python minor version; or multiple redundant installations of the same version. Indeed, on Windows you simply won't be able to install multiple patch versions of the same Python version, except perhaps if one is installed for all users and the other is user-specific. (On Linux, of course, you can always compile whatever versions you like from source; but you're on your own for "installing" them and keeping track of where they are.)

But to reiterate: if you have a separately built version of Python that is not explicitly "installed" but is still usable, you can still always choose to use it by explicitly specifying the path to the specific Python executable.

If you use virtual environments, therefore, you can still specify the path to the executable (whether a symlink or a separate file) created for that virtual environment. Alternately, you can activate the virtual environment by using the activation script it provided. This works by temporarily modifying PATH (and decorating the terminal prompt as a reminder), and setting up a deactivation command that will undo the changes. There is otherwise nothing special about activating a virtual environment (unless of course your script somehow depends on that change to PATH).

posted 21 days ago

CC BY-SA 4.0

21d ago

Karl Knechtel‭

1790 reputation 32 47 228 68