apt-get install vs pip install

I am a bit confused about the cases in which the above commands must be used when downloading python packages. I was trying to download a package named pyudev in accordance with an answer with this question. I executed this command :

sudo pip install python-pyudev

but received the following message :

Downloading/unpacking python-pyudev

  Could not find any downloads that satisfy the requirement python-pyudev
Cleaning up...
No distributions at all found for python-pyudev
Storing complete log in /home/vineet/.pip/pip.log

However the following worked fine :

sudo apt-get install python-pyudev

When is apt-get supposed to be used to install packages and when is python-pip used?

Solution 1:

PyPI is the Python Package index — repository of python modules.

pip is used to download and install packages directly from PyPI. PyPI is hosted by Python Software Foundation. It is a specialized package manager that only deals with python packages.

apt-get is used to download and install packages from Ubuntu repositories which are hosted by Canonical.

Some of the differences between installing python packages from apt-get and pip are as follows:

Canonical only provides packages for selected python modules. Whereas, PyPI hosts a much broader range of python modules. So, there are a lot of python modules which you won't be able to install using apt-get.
Canonical only hosts a single version of any package (generally the latest or the one released in recent past). So, with apt-get we cannot decide the version of python-package that we want. pip helps us in this situation. We can install any version of the package that has previously been uploaded on PyPI. This is extremely helpful in case of conflict in dependencies.
apt-get installs python modules in system-wide location. We cannot just install modules in our project virtualenv. pip solves this problem for us. If we are using pip after activating the virtualenv, it is intelligent enough to only install the modules in our project virtualenv. As mentioned in previous point, if there is a version of a particular python package already installed in system-wide location, and one of our project requires an older version of the same python package, in such situations we can use virtualenv and pip to install that older version of python package without any conflicts.
As @Radu Rădeanu pointed out in this answer, there would generally be difference in names of packages as well. Canonical usually names Python 2 packages as python-<package_name> and Python 3 packages as python3-<package_name>. Whereas for pip we generally just need to use <package_name> for both Python 2 as well as Python3 packages.

Which one should you use:

Both apt-get and pip are mature package managers which automatically install any other package dependency while installing. You may use anyone as you like. However, if you need to install a particular version of python-package, or install the package in a virtualenv, or install a package which is only hosted on PyPI; only pip would help you solve that issue. Otherwise, if you don't mind installing the packages in system-wide location it doesn't really matter whether you use apt-get or pip.

Solution 2:

As @AvinashRaj said in his comment, pip is used to install python packages only, but apt-get is used to install packages created in any programming language.

Your main problem is to find the right package name in both cases:

pip search pyudev

will give you the right name for the package you want to install using pip install, as

apt-cache search pyudev

will give you the right name for the package you want to install using apt-get install:

radu@Radu: ~ $ pip search pyudev
pyudev                    - A libudev binding
radu@Radu: ~ $ apt-cache search pyudev
python-pyudev - Python bindings for libudev
python3-pyudev - Python3 bindings for libudev

So, in conlusion, the correspondent of sudo apt-get install python-pyudev is sudo pip install pyudev, not sudo pip install python-pyudev.

Now depends on you what you want to choose when you want to install a python package: pip or apt-get. See for example this Q&A about difference in installing a package using pip and apt-get.

Solution 3:

My preferred way is to always use apt and only in case the module is not yet available in Debian/Ubuntu repository to use pip, but only in user context - --user flag. By using pip one anyway have to get all the build-dependencies installed from let's say Ubuntu's repository or provide them themselves which can be a tedious task. apt-get install binary packages while pip builds them after downloading. One shouldn't use pip to install modules into system locations. This is plain wrong. Always use --user flag to install a module to home location. Properly configured PYTHONPATH let python to pick up the modules from the HOME first and then system modules installed with apt-get.

Solution 4:

This is the advice given on a widely linked issue on the GitHub pip site on the subject of system installed pip vs local installed pip:

Only ever use your system package manager to upgrade the system pip. The system installed pip is owned by the distribution, and if you don't use distribution-supplied tools to manage it, you will hit problems. Yes, we know pip says "you should upgrade with pip install -U pip" - that's true in a pip-managed installation, ideally distributions should patch this message to give appropriate instructions in the system pip, but they don't. We're working with them on this, but it's not going to happen soon (remember, we're looking at cases where people are upgrading old versions of pip here, so patches to new versions won't help).

Never use sudo with pip. This follows on from the first point. If you think you need to use sudo, you're probably trying to modify a distribution-owned file. See point 1.

Prefer to use --user. By doing this, you only ever install packages in your personal directories, and so you avoid interfering with the system copy of pip. But there are PATH issues you need to be aware of here. We'll cover these later. Put simply, it's possible to follow this advice, and still hit problems, because you're not actually running the wrapper you installed as --user.