Multiple Python versions on Linux in user space

Is there an easy way to have multiple Python versions on Linux without affecting the system Python? Specifically, I’m using Ubuntu 20.04.5 with its Python 3.8.10. I would like to have the newest version available in my user space, too. There are multiple sources online advising usage of update-alternatives, but AFAIK, this will affect system Python.

Checkout pyenv

2 Likes

Does it work well with venv? Also, I found this in Python documentation (venv — Creation of virtual environments — Python 3.12.1 documentation):

Deprecated since version 3.6: pyvenv was the recommended tool for creating virtual environments for Python 3.3 and 3.4, and is deprecated in Python 3.6.

Running multiple Python versions can be anything between a big mess and a plain nightmare. The only way out of it is to use venv, a “Python Virtual Environment”.

I wrote a “HOWTO - Using Python in a virtual Environment on Linux” download from here: GeigerLog - Browse /Articles at SourceForge.net

As I need to do version testing for my software, I can now run Py3.5, Py3.6, Py3.7, Py3.8, Py3.9, Py3.10, and if I want to, even all of them simultaneously!

1 Like

Perhaps a bit much for some folks, but in order to develop against
the latest of each Python minor version, I git checkout the relevant
tag from the cpython repository, and “simply” do (approximately)
./configure --prefix $HOME/lib/cpython/$TAG followed by make
and then make altinstall so it’s installed into a dedicated tree
in my homedir. Then ln -sf ../lib/cpython/$TAG/bin/python3.* ~/bin/ and since ~/bin is included in my path, invoking python3.11
or whatever “just works” for me. Note that all of this can be done
as your normal user, no need for any root privileges.

I’ve been including --enable-optimizations --with-lto in my
configure options for a while, though I need to revisit whether
they’re still relevant. On my development systems, adding -j32
to make is roughly the sweet spot for build-time parallelization.
It’s also a good idea to do something like make test before
doing the altinstall, just to double-check that things built sanely.
If you need the build dependencies, on Ubuntu it’s a quick sudo apt-get build-dep python3 to get them (that does need root privs
of course, hence the sudo I included there).

If you, like me, create venvs with these for your development tools
like tox or twine, you’ll also want to remember to regenerate them
any time you recompile/replace the interpreter for which they were
built.

1 Like

I use make altinstall then Pycharm which takes care of the virtual environment for me without me having to think. In Pycharm you can select any installed interpreter (Python version). Works on Unix and wondows.

1 Like

Does it work with VS Code? I know it detects installed C/C++ compilers quite well. Will it detect Python installed through altinstall?

No I don’t think so VS code is not that smart, its pretty smart, but its is extremely flexible and hence you can set the interpreter here. BTW I use both Pycharm and VS code for different things. VS code is very good at getting the file you want type CTL-p and start typing file name and it presents a selection (but Pycharm you need to go via menu for (Navigate) Search Everywhere). VS code is good for git and shows you the history changes in Timeline.

Pycharm is very good for testing and editing python code, also very good at linting.

1 Like

I finally found time to implement and start using a simple scheme, which works quite well for me so far. On my Ubuntu 20.04.5 with Python 3.8.10, I installed Python 3.10.4 with:

sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt install python3.10 
sudo apt install python3.10-dev python3.10-venv python3.10-distutils python3.10-tk

I’m doing my work in virtual environments created for a specific Python version, e.g.:

python3.10 -m venv .venv10

VSCode plays nicely with this scheme. The system Python is not affected.