update-alternatives does not work due to /usr/local/bin precedence

I have faced with an issue that when I search proper version of python I every time found python 3.7:

python3 --version Python 3.7.0

Then I have checked update-alternatives configuration:

sudo update-alternatives --config python3
There are 3 choices for the alternative python3 (providing /usr/bin/python3). Selection Path Priority Status
------------------------------------------------------------ 0 /usr/local/bin/python3.7 2 auto mode 1 /<HOME_DIR>/Software/anaconda3/bin/python3 1 manual mode
* 2 /usr/bin/python3.6 1 manual mode 3 /usr/local/bin/python3.7 2 manual mode

Then I have checked location of the python3:

which python3
/usr/local/bin/python3

Then I have checked PATH:

echo $PATH
/usr/lib/x86_64-linux-gnu/dbus-1.0/include:/usr/local/lib/boost/include:/<HOME_DIR>/bin:/<HOME_DIR>/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/<HOME_DIR>/.dotnet/tools

Turns out that python3 has found in /usr/local/bin before the searching in /usr/bin

Why update-alternatives has not created the link in /usr/local/bin for maintaining for proper searching of application ?

I do not want to remove python3 from /usr/local/bin, but in this case update-alternatives becomes useless

How to fix it that update-alternatives create links also in /usr/local/bin ?

1 Answer

To answer your first question

Why update-alternatives has not created the link in /usr/local/bin for maintaining for proper searching of application ?

This is simply because alternatives for python3 is configured at the moment to create the symbolic link in /usr/bin. From your output above:

sudo update-alternatives --config python3
There are 3 choices for the alternative python3 (providing /usr/bin/python3).
...

It pretty normal for any Linux distribution to search /usr/local/bin before /usr/bin for executables, as this gives you the freedom to put any binaries and libraries into /usr/local without interfering with the dpkg packages.

For you specific problem and from the output of sudo update-alternatives --config python3 I guess /usr/local/bin/python3 is a symbolic link to /usr/local/bin/python3.7

root@host:~# ls -l /usr/local/bin/python3
lrwxrwxrwx 1 root root 25 Sep 22 15:36 /usr/local/bin/python3 -> /usr/local/bin/python3.7

If that is the case, just remove the symbolic link /usr/local/bin/python3 and you should be fine, since when calling python3 only /usr/bin/python3 is found, which should point to /etc/alternatives/python3 which in turn should point to the selected binary.
If /usr/local/bin/python3 is not a symbolic link, rename it and configure update-alternatives appropriately.

While this might save you for now, the next update might render your configuration useless again. The symbolic link /usr/bin/python3 is shipped with the package python3-minimal and by managing this link with update-alternatives the symbolic link is broken from the view of the python3-minimal package. The next update of this package could fix this problem, but then the link is broken from the view of update-alternatives.

To come around both problems, it would be better to configure update-alternatives to use /usr/local/bin/python3 as the symbolic link providing the selected version.
To do so, the steps as follows should do the trick, including fixing the /usr/bin/python3 link.

sudo update-alternatives --install /usr/local/bin/python3 python3 /usr/bin/python3.6 2
apt-get install --reinstall python3-minimal