How to Install pip for Python (Step by Step)

What pip does, and why it may be missing

pip is the package installer that ships with Python. It pulls libraries from the Python Package Index and resolves their dependencies along the way. If you installed Python from python.org, you already have it. If you are on Linux, your distribution has probably moved it into a separate package — which is why so many people meet pip for the first time through an error message.

This guide walks through three questions in order. Is pip already there? If not, how do you get it? And why does pip install refuse to run on a freshly installed Debian or Ubuntu even when everything looks correct? Version numbers here are current as of September 2026.

One pip per Python, not one per machine

The name is a recursive acronym: “Pip Installs Packages”. It fetches a package from PyPI, installs it into the environment the calling interpreter points at, and brings in whatever else that package needs.

The middle part of that sentence is the one worth remembering. pip does not belong to your operating system; it belongs to one particular Python installation. On macOS and Linux you almost always have several side by side — the system one, one from Homebrew or pyenv, plus every virtual environment you create. A bare pip hits whichever of them comes first in $PATH. Writing python3 -m pip instead states which interpreter you mean, and the official Packaging User Guide uses that form throughout. Adopting the habit removes most of the confusion before it starts.

The current release is pip 26.2.1, published on 4 August 2026, and it requires CPython 3.10 or newer (project page on PyPI). The latest Python release is 3.14.4.

Step 1: check whether pip is already installed

Open a terminal and ask for the version:

python3 -m pip --version

The answer gives you three things: the pip version, the path pip lives in, and — in brackets — the Python version it belongs to. On Windows the equivalent is py -m pip --version.

If you get No module named pip, pip is missing for that specific interpreter. If you get command not found, it may only be a path problem, so check with python3 --version whether Python itself is installed at all. Either way, continue with step 2.

Step 2: install pip

The pip documentation lists two supported methods, and on Linux your package manager is a third route. Try them in this order.

1. ensurepip. Since Python 3.4 the standard library carries a module that installs pip from files already on disk — no download, no administrator rights:

python3 -m ensurepip --upgrade

2. Your distribution’s package manager. On Debian and Ubuntu the first route usually leads nowhere. The Debian Python Policy states that modules which would interfere with system package management — naming ensurepip outside virtual environments explicitly — are shipped in a modified form that prints an explanation instead. There, pip and the venv module come from their own packages:

sudo apt install python3-pip python3-venv

3. get-pip.py. A bootstrap script that downloads pip and sets it up. It is the second officially supported method and the right choice once the other two are ruled out:

curl -O https://bootstrap.pypa.io/get-pip.py
python3 get-pip.py

There is a reason get-pip.py sits at the bottom of this list rather than the top: it writes around your package manager. On a system that maintains pip as a package of its own, you end up with two installations that can overwrite each other. Windows and macOS rarely raise the question, because the installers from python.org include pip. On Windows, tick “Add Python to PATH” during setup, or the command prompt will not find the interpreter afterwards.

Why a virtual environment is no longer optional

This is where older tutorials fall apart. Current Linux distributions no longer let pip write into the Python installation the system itself maintains. The basis is a Python Packaging Authority specification: a marker file called EXTERNALLY-MANAGED in the stdlib directory tells tools such as pip “that they neither install nor remove packages into the interpreter’s default installation environment” (Externally Managed Environments).

When pip finds that file and is running outside a virtual environment, it stops. The message reads error: externally-managed-environment, followed by “This environment is externally managed” and a note the distribution itself writes into the marker file. Nothing is broken: this is the normal state of Debian, Ubuntu, Fedora and Raspberry Pi OS.

The answer is one environment per project, not a way around the block:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install requests

The middle line is for bash and zsh. On Windows it becomes .venv\Scripts\activate.bat in the command prompt and .venv\Scripts\Activate.ps1 in PowerShell; the venv documentation has a table covering the remaining shells. You do not need to install pip inside the environment: unless you pass --without-pip, venv invokes ensurepip itself while creating it.

The specification does provide an escape hatch, --break-system-packages, and describes it as something that “should carry some connotation that its use is risky”. The name is the warning, and putting sudo in front makes it worse rather than better — see our article on using sudo on Debian. If what you want is a finished command line program available system-wide rather than a library inside a project, use pipx: it builds a separate environment per program and only links the entry point into your $PATH. The monitoring tool from our article on Glances is a typical candidate.

The pip commands you actually use

Four commands cover most of the work. Each of them also works with python3 -m pip in front, and outside an activated environment that is the safer spelling.

1.Install packages:

pip install package_name

Without a version, pip takes the newest release compatible with your Python. package==1.2.3 pins one version, package>=1.2 sets a lower bound. Several packages may share one call.

2.List installed packages:

pip list

What you see is the contents of the active environment, not of the machine — run it in two project directories and you get two different lists. To produce a file you can replay elsewhere, use pip freeze > requirements.txt and later pip install -r requirements.txt. pip show packagename reports version, origin and dependencies of a single package, and pip check reports dependencies that are not satisfied.

3.Update a specific package:

pip install --upgrade package_name

The documentation is precise about what this does and does not guarantee: the named package is updated, its dependencies only “if their installed versions do not meet the minimum requirements”. Raising everything at once is a job for a maintained requirements.txt, not for a single catch-all flag.

4.Uninstalling a package:

pip uninstall package_name

Only the named package goes. Everything that was installed on its behalf stays: after pip install requests and a subsequent pip uninstall requests, certifi, charset-normalizer, idna and urllib3 are still listed by pip list. That is the practical argument for a throwaway environment per project: you delete the .venv directory and start clean instead of tidying up by hand.

Troubleshooting: the four errors you will actually hit

“error: externally-managed-environment”. Not your mistake, but the block described above. Create a virtual environment and install into it. --break-system-packages only appears to solve the problem, and it gambles with the Python installation your system tools depend on.

The package is installed but the import fails. The most common case by far, and nearly always the same cause: you installed into one environment and ran the script from another. Compare the path printed by python3 -m pip --version with the one from python3 -c "import sys; print(sys.executable)". If they differ, you have found it. Using python3 -m pip install … instead of pip install … prevents the mismatch in the first place.

“Permission denied”. pip is trying to write into a directory you do not own. The answer is not sudo but, again, a virtual environment; at a pinch, pip install --user packagename will do. Packages installed as root end up owned by root and produce permission problems later that are harder to diagnose than the original message.

pip itself is out of date. Inside an activated environment, python -m pip install --upgrade pip raises the version. Outside one, leave it alone and update your distribution’s package instead. To rule the mistake out permanently, pip offers --require-virtualenv, documented as “allow pip to only run in a virtual environment; exit with an error otherwise”. Exported as PIP_REQUIRE_VIRTUALENV=1 in your shell configuration it applies to every call — our article on shell aliases covers how to make such settings stick.

Conclusion

Three things are worth taking away. Check with python3 -m pip --version before installing anything, because pip is often already there. If it is missing, try ensurepip or your package manager before reaching for get-pip.py. And give every project its own python3 -m venv .venv — the habit that saves the most time, and the reason externally-managed-environment will never concern you again.

FAQ