Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Why does `pip` seem to be missing or broken? Isn't it part of the standard library?
I already know that the pip command might not correspond to the same Python that python runs. But in my case, it seems not to exist at all. I can't even run it as a Python module:
$ python -m pip
/usr/bin/python: No module named pip
What gives? I thought each copy of Python is supposed to have its own Pip?
1 answer
Contrary to popular belief, Pip is not part of the Python standard library - although it comes as part of a standard distribution of Python. Pip is developed and maintained by the arms-length Python Packaging Authority, which allows it to be versioned independently of Python (developed by the core Python development team, under the umbrella of the Python Software Foundation).
Typically, when Python is installed, Pip is bootstrapped into the distribution's site-packages third-party library. This is done by running the ensurepip standard library package after the main part of the installation. Basically, the Python source code distribution contains a specific, pre-made "wheel" for Pip (a specific version corresponding to each Python version), which ensurepip copies into place. ensurepip will also create and install the expected wrapper executables so that the pip command can work.
So, ordinarily, if Pip is missing, python -m ensurepip would be enough to restore it. However, Python provided as part of Debian Linux (and downstream distros) deliberately disables this:
Important notes for Debian-based Linux distros
The included ensurepip has been modified to remove the "vendored" wheel (although there may be a Pip wheel in /usr/share/python-wheels, to support virtual environment creation) and so that a diagnostic message is displayed instead if you try to use it outside of a virtual environment:
$ python -m ensurepip
ensurepip is disabled in Debian/Ubuntu for the system python.
Python modules for the system python are usually handled by dpkg and apt-get.
apt install python3-<module name>
Install the python3-pip package to use pip itself. Using pip together
with the system python might have unexpected results for any system installed
module, so use it on your own risk, or make sure to only use it in virtual
environments.
You can use the system package manager to add Pip to the system Python by following the instructions from the diagnostic message. However, this is discouraged, because of the risks involved.
Installing packages for the system Python in the default location (i.e. the system Python's own site-packages folder) requires root privileges. Please never use sudo to run Pip. Pip installation supports running arbitrary code from setup.py which would run with root privileges in this situation. Newer versions of Pip will default to a "user" install in this situation, putting the installed library in a version-specific subdirectory within $(HOME)/.local/lib. (With older Pip you may need to specify --user explicitly.) Packages installed here will still be recognized when running the system Python, so they could still theoretically interfere with critical system scripts; but at least the root filesystem will be protected during installation.
It's not necessary, anyway to install Pip for the system Python in order to do Python development. Instead, just create a virtual environment (you may have to install venv for the system Python). By default, ensurepip will run in the new virtual environment and bootstrap Pip into that environment.
The basic idea here is that Debian wants you to use the system package manager (apt) to install third-party libraries for the system Python, rather than Pip. That way, they can explicitly vet specific packages for installation in the system Python and add their own patches.
This is called "external management", and newer versions of Pip (such as included with Python 3.11) can cooperate with Debian to recognize this "externally managed environment". Thus, newer versions of Pip will report an error when you try to use it with the system Python, unless you explicitly pass --break-system-packages as a confirmation. Other distros may use this marker system even if they provide Pip by default.
0 comment threads
0 comment threads