Managing multiple python version without any tool

Does Python officially recommend any tool to manage different python version?

How complex would that be if I try to do it myself manually? For example, I could just have different python version on my system, and use their fully specified path just to start a local environment. What could be possible issues is this setup? One I could think of is with system wide python package cache, and the effect of these different version trying to write on the same location.

Any insight would be appreciated, of feel free to forward me to online resources. I am sure this topics has been beaten to death, but I am looking for something SUPER simple(i.e. a bash script) and trying to avoid any new tools like pyenv.

This is completely standard and should work. Even with a management tool like pyenv, ultimately there are just multiple installed versions of Python.

If you simply install multiple versions of Python [1], they will generally stay out of each others’ ways. On my Linux system, I can type python3 to get the default Python, or python3.5 or python3.8 or python3.13 to ask for a specific version. If you invoke a specific Python when creating a virtual environment, that will become the default Python within that environment, too, making it easy to manage your apps’ venvs. (As an example of that: I have some Python apps which are hosted on Heroku, and so my local venv is always synchronized with the Python version running on production.)

So, how simple is it? You just install multiple and they stay out of each others’ way :slight_smile:


  1. assuming they’re all different minor versions - you can’t easily have both 3.10.0 and 3.10.1 installed, but nobody needs that anyway ↩︎

1 Like

Depends on what you mean by “simple” but I “simply” compile all the
versions of cpython I want to use and make altinstall them into
subdirectories under ~/lib, then I make symlinks in ~/bin to their
respective python3.X executables and have my bashrc set to add that
directory to my $PATH. It’s quite straightforward and hasn’t caused
me any trouble, currently have the following in use on my Debian Sid
workstation:

$ python3.8 --version
Python 3.8.18
$ python3.9 --version
Python 3.9.18
$ python3.10 --version
Python 3.10.13
$ python3.11 --version
Python 3.11.8
$ python3.12 --version
Python 3.12.2
$ python3.13 --version
Python 3.13.0a5
1 Like

It depends what you mean by “manage”. But it seems like you have very light-weight “management” in mind, so this is a very easy problem, and no external tools are really needed.

Fortunately for you, this is already built in. Just use the standard library venv module to create a virtual environment (which is exactly the sort of local environment you describe, except that it may use symlinks to installed Python interpreter etc. executables somewhere else, and it is not relocatable). It will have its own completely separate storage location for third-party packages, and will come with its own “activation” bash script for temporarily mangling PATH so that python means the one in that environment. (It also adjusts the prompt via PS1 to remind you that the environment is “active”.) Running the script looks like source /path/to/venv/bin/activate; while the environment is active, deactivate (a bash function created by the script) means to undo the changes.

If you want multiple different versions of Python, that is also trivial. Each installation already has a separate storage location for third-party packages (it must, because not all packages are compatible with all Python versions), and a separate standard library.

If you want to control which version of Python runs when you use a command like python, outside of virtual environments, see the documentation for Python, and on Linux you should also consult your distro’s documentation. It might not be a good idea to alias python or make permanent alterations to PATH - since the system may depend on system-provided scripts running with a specific system-provided Python version. Your system package manager might also provide convenience packages for this, which re-alias the commands and ensure nothing will break. (For example, Ubuntu users may find they can apt-get things with names like python-is-python3.)

If you want a virtual environment based off a specific version of Python, you just use its standard library venv module: /path/to/pythonXY -m venv venv_name.

3 Likes

This is exactly what I was asking(implying). Thank you!

Doesn’t this conflict with the system Python, which presumably is a separate installation but matches one of these minor version numbers?

That depends on what order you put directories in your $PATH. The
user is free to choose whether ~/bin or /usr/local/bin or /usr/bin
or /bin or something else entirely takes priority. With creative use
of symlinks, your custom Python 3.10 could be foobar3.10 or xyzzy or
plugh…

2 Likes