Changing Python's default version breaks Ubuntu 20.04

Question

I'm creating an AMI of Ubuntu 20.04 (Focal Fossa), and I want the default Python version to be 3.6.

I installed Python 3.6, also the right pip, and then set the alternative like so:

update-alternatives --install \
  /usr/bin/python3 \
  python3 \
  /usr/bin/python3.6 \
  10

But then I'm running into many issues related to CPython packages, such as python3-apt (apt_pkg, apt_inst), netifaces, and probably many more I didn't catch yet.

They are all located on /usr/lib/python3/dist-packages and the package names are in this format:

{name}.cpython-38-x86_64-linux-gnu.so

Which makes sense, since the default Python version of Ubuntu 20.04 is Python 3.8.

The immediate solution from googling is linking the name like so:

ln -s {name}.cpython-38-x86_64-linux-gnu.so {name}.so

I.e.:

ln -s apt_pkg.cpython-38-x86_64-linux-gnu.so apt_pkg.so
ln -s netifaces.cpython-38-x86_64-linux-gnu.so netifaces.so

I tried reinstalling the relevant packages (apt install --reinstall python3-apt) when the default Python version is 3.6, but it didn't work, and this solution of linking the *.so files is not scalable!

Is there a way to make Python 3.6 work with the system's default CPython packages?

Answer 1

As you discovered, the system does rely on the system version of Python being as it expects. If you really want a system with Python 3.6, your best bet is to find a (ideally, still supported) release using Python 3.6: in your case, Ubuntu 18.04.

If you want to provide Python 3.6 for programs running on your AMI, you could look into using virtual environments instead of replacing the system Python. pyenv is a good place to start.

Answer 2

Administer the environment of any machine on the cloud as you would that of a physical machine near you. If you work with Ubuntu 20.x and your default Python installation on it is 3.8, but you require Python v3.6, install a virtual environment as needed. You can do that with pyenv. What you are doing at the moment is breaking your default Python installation in slow motion with all the adverse effect this will have on countless packages on that machine (cloud based or not).

I add a tutorial I wrote on the virtualization of Python environments, in case of interest (in particular in pyenv).