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 ?
Best Answer
To answer your first question
This is simply because
alternatives
forpython3
is configured at the moment to create the symbolic link in /usr/bin. From your output above: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.7If 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 withupdate-alternatives
the symbolic link is broken from the view of thepython3-minimal
package. The next update of this package could fix this problem, but then the link is broken from the view ofupdate-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.