pip: the package installer Python ships with, and what it actually does

What pip solves, and who is actually installing it

Python's standard library has no downloader for third-party distributions. pip fills that gap: it reads package metadata, fetches wheels or source archives from an index, and puts the result where the running interpreter can import it. The README states the scope in one line, that pip is the package installer for Python and that you can use it to install packages from the Python Package Index and other indexes.

The audience is broader than application developers. Anyone who runs a Python script that imports something outside the standard library eventually runs pip, including data analysts, CI authors and people writing one-off automation. The project classifiers list the intended audience as developers and the development status as production/stable, which matches how it is used in practice: as infrastructure, not as an application.

What pip deliberately is not matters as much. It is not a virtual environment manager, not a build backend (the repository's own build uses flit-core), and not a lockfile generator. Those boundaries are why the packaging guide it links to recommends separate tools for separate jobs.

Inside a pip install: resolution, wheels, and where it writes

A pip run is a pipeline. The command line is parsed, then pip collects requirements from the arguments and from any constraints or requirement files. It queries the configured index for each candidate distribution, which by default is PyPI. The resolver picks a set of versions that satisfies every requirement, preferring the newest compatible release. Then it downloads the selected artifacts, and for each one either installs the wheel directly or builds a wheel from a source distribution first.

Two details shape day-to-day behaviour. First, wheel installation is a file copy into site-packages, while a source distribution triggers a build that needs a working compiler or the build dependencies declared by the project. Second, pip installs into the environment of the interpreter it is bound to, which is why the same pip command can behave differently in a virtual environment and outside one. The repository's own pyproject.toml shows the same pattern from the other side: pip itself is built with flit-core, and it declares requires-python >=3.10, so the resolver on an older interpreter will refuse the newest pip.

pip vendors its dependencies. The license-files list in pyproject.toml points at src/pip/_vendor/**/*COPYING* and *LICENSE* files, which is the visible trace of that policy: pip carries the libraries it needs so that an installation does not depend on what happens to be present on the target machine.

Installing pip and running a first install

Most Python installations already include pip. The README does not inline installation steps; it links to the Installation page at pip.pypa.io, which is where the supported paths live. The README also names the bootstrap script, bootstrap.pypa.io/get-pip.py, as the route people search for when pip is absent. That script is run with the interpreter you want pip attached to.

The repository's pyproject.toml declares two console entry points, both pointing at the same module:

[project.scripts]
pip = "pip._internal.cli.main:main"
pip3 = "pip._internal.cli.main:main"

That is why pip and pip3 are the same program, and why the interpreter a command is bound to matters more than the name you type. Once pip is present, a first real use is installing a distribution and then listing what is there. The README gives no example commands of its own; the Usage page it links to is where the command forms are documented, so check that page for the exact spelling of any flag before you copy it into a script.

What you should see after an install is the distribution recorded in the environment of the interpreter that ran the command. If the same command appears to do nothing, the usual cause is that pip and python resolve to different installations.

Where pip stops being the right tool

pip resolves at install time, against whatever the index holds at that moment. Two installs of the same requirements file on different days can produce different transitive versions. That is a design position, not a bug: the project's own documentation links out to the packaging guide's tool recommendations rather than claiming to solve reproducibility itself. If your deployment needs the same tree every time, pip alone will not give it to you.

The second boundary is the environment. pip has no concept of a project sandbox. Run it outside a virtual environment and it writes into the interpreter's global site-packages, where it can conflict with system-managed packages. On distributions that mark their Python as externally managed, pip refuses the install and points at the system package manager or a virtual environment instead. That refusal is the correct behaviour and a common source of confusion for people copying commands from older tutorials.

The third is scope. pip installs and uninstalls distributions. It does not build your project, run your tests, or manage the interpreter version. The repository reflects this separation: the build backend is flit-core, the test runner is pytest, and the automation lives in noxfile.py. Treating pip as the whole packaging story leads to requirements files that nobody can rebuild.

pip compared with a lockfile-first installer

The closest alternative in current Python practice is uv, which resolves dependencies and writes a lockfile so that installs are reproducible across machines, and which also manages virtual environments and interpreter versions. The difference in approach is when the decision is made. pip decides during installation, reading the index live. A lockfile tool decides once, records the exact versions and hashes, and replays that decision later.

That difference cuts both ways. A lockfile gives you repeatability but adds a file to maintain and a step to remember when you intentionally upgrade. pip gives you the newest compatible set with no extra artifact, which is convenient for libraries and for interactive work, and risky for servers. The two are not exclusive: teams commonly let a lockfile tool produce the pinned set and let pip consume it, since pip can install from a requirements file with pinned versions.

A narrower alternative is pipx, which installs command-line applications into isolated environments so that their dependencies do not pollute a project environment. That is a different problem: pipx wraps pip's installation model for applications rather than replacing the resolver.

Maintenance cadence, licensing and upgrade cost

The README states that releases happen regularly, with a new version every 3 months, and points at the release notes and release process pages for detail. The repository is not archived, and the last push was on 2026-09-21, so the codebase is current. Because pip is bundled with CPython, many users receive upgrades without doing anything; the ensurepip route exists for the cases where the bundled copy is stale or absent.

Upgrade cost is mostly about the interpreter floor. The pyproject.toml in the repository declares requires-python = ">=3.10" and lists classifiers through Python 3.15, so the current line of pip will not install on older interpreters, and those environments are pinned to older pip releases. The same file notes that requires-python is duplicated in __pip-runner__.py and asks contributors to change both copies, a small example of the maintenance overhead that comes with a bootstrap script.

Licensing: pip is MIT, declared in pyproject.toml as license = "MIT" with license-files listing AUTHORS.txt, LICENSE.txt and the vendored COPYING and LICENSE files. The vendored dependencies carry their own licenses, which is why those globs are enumerated rather than covered by a single notice. If you redistribute pip or a vendored component, read those files; this article is not legal advice.

Security reporting goes through SECURITY.md in the repository root, not the public issue tracker.

Editorial conclusion

Adopt pip if you are installing Python packages from an index into an environment you control, or if you are building tooling that has to speak the same command line every Python user already knows. Do not reach for it as a dependency lockfile, a build backend, or a way to pin an application's full transitive tree; pip resolves and installs, it does not guarantee reproducibility, and the project points at other tools for that. Before you rely on it in CI, verify two things on your own machines: which Python interpreter your pip entry point belongs to, and whether your index needs a non-default index URL because PyPI is the default. The pyproject.toml in the repository declares requires-python >=3.10, so anything older needs an older pip release.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. pypa/pip on GitHub
5. README