Can someone tell me why there is an executables for python 2,2.7,3 and 3.5 located in usr/bin; python 2.7,3, and 3.5 folders located in usr/lib which seem to be the actual contents all save for 3 which contains distribution-packages; then in my home directory there is a .local/lib file which contains site-packages for python 2.7 and 3.5.

I really just dont understand why all these things are spread out and why there are duplicates of things just kinda running around the system. Linux you confuse me!!!!!

Oh wait there's more: in usr/local/lib I find: python2.7 and python 3.5 which contain more dist-packages....

In /usr/bin, python2 isn't an executable, it's a link to the installed Python 2 executable python2.7. As indeed is plain python.

Similarly, python3 links to the installed python3.5.

These links mean that e.g. "python2" can be run and it will automatically run the latest version of Python 2. This is a great advantage to programs as they don't need to know the version of Python on the computer to run it.

Your system has both version 2.x and version 3.x installed because some Python scripts need Python 2 and others need Python 3. That is normal.

You need to read up on what /usr/bin, /usr/lib and /usr/local/lib are used for, and how user-specific info and configuration is kept in (mostly) .dot files and directories in the user's home directory.

Normally this is of no concern, but when you try to update your version of Python by compiling and installing a different version of Python as a relative newbie (as you did here https://www.linuxquestions.org/quest...on-4175634396/) then there is a high likelihood that you are going to face problems.

That is why I suggested that you find a rolling release distro if you want an easier way of using a more up-to-date version of Python 3. Your reply to my suggestion was a simple "confused face" and you asked me no questions about how to do this.

So, vysero, you have some explaining to do.

I guess the answer is, because you put it all over when you compiled from source! But good job finding all that stuff.

At least something good happened, .

This link might explain as well: https://passingcuriosity.com/2015/in...n-from-source/

Maybe you guys could help me understand why I can't seem to get rid of the python3.7 I installed from source. Its located in usr/local/lib but when I do a sudo apt-get remove python3.7 or a sudo apt-get purge python3.7 I get:

Also, I have noticed that the pre-installed 2.x and 3.x versions of python are located in my home directory @ home/.local/lib; however, python3.7 which I installed from source is not located there? The 2.x and 3.x only contain site-packages but I guess I would have expected there to be a 3.7 with site-packages. The only place I can find 3.7 site packages is in usr/local/lib/python3.7.

I believe I can use python3.7 if I can just figure out how to get pip installed for it. The odd part is that in usr/local/lib I find: python2.7, python3.5 and python3.7 folders but the 2.7 and 3.5 folders (pre-installed) only contain dist-packages whereas the 3.7 contains the full install, that can't be right can it? How am I supposed to get pip into site-packages for 3.7 when its only locating is in usr/local/lib which I can't change the contents of?

When you install a program from source, you are doing it "behind your package manager's back". This is not normally a good idea! As you have now found out, asking the package manager to get rid of the installed program won't work because, as far as it knows, there is no such program installed.

Programs that were built and installed by hand must be uninstalled by hand. Build your python afresh, making sure you use the same build parameters as before, but this time, instead of "sudo make install", use "sudo make uninstall". The package's own scripts will then remove all the unwanted files from the locations where they were originally copied to.

Here is a link to the build I used (method 1):
https://www.linuxbabe.com/ubuntu/ins...04-16-10-17-04

As you can see it uses the command sudo make altinstall. I tried opening the source directory in the terminal and typed sudo make uninstall but it told me:

If the make file lacks an uninstall section (and it can occasionally happen) then you have to do it the hard way. The unstall section tells the make command what has to be installed and where, so you can read it yourself and remove each file manually. At least you've already worked out where the go!

If you compile from source and install, it's always a good idea to keep the make file in a safe place just in case you need to uninstall. Some irritating programs will actually tell you to uninstall the old version before compiling and installing the new one.

So I pulled up the make file and searched for the keyword: uninstall but nothing came up. So I guess that means I am doing this the hard way? What does that entail should I just log in as admin and manually delete the folder?

There was a typo in David's post. He wrote "unstall" when he actually meant "install". Look again in your Makefile for "make install". That's where you will find the list of installed files and where they went.

Ah I see. Well if I search the Makefile for "make install" there is only one hit. So Maybe this isn't the actual makefile?

At the top of the file it does say:

# Generated automatically from Makefile.pre by makesetup.
# Top-level Makefile for Python
#
# As distributed, this file is called Makefile.pre.in; it is processed
# into the real Makefile by running the script ./configure, which
# replaces things like @spam@ with values appropriate for your system.
# This means that if you edit Makefile, your changes get lost the next
# time you run the configure script. Ideally, you can do:
#
# ./configure
# make
# make test
# make install
#
# If you have a previous version of Python installed that you don't
# want to overwrite, you can use "make altinstall" instead of "make
# install". Refer to the "Installing" section in the README file for
# additional details.
#
# See also the section "Build instructions" in the README file.