pip: The Python Package Installer

pip install httpx looks like a single, simple action, but pip performs genuine dependency resolution behind that one command: it reads httpx's own declared dependencies (from its package metadata), recursively resolves *those* dependencies' own dependencies, and searches for one specific version of every package in the resulting tree that simultaneously satisfies every version constraint from every other package depending on it — exactly the resolution process covered conceptually in the Dependency Management lesson, with pip as one of several concrete tools that perform it (uv and Poetry, covered in the next lessons, are others).

Modern pip (since the 2020 rollout of its new resolver) performs this resolution more rigorously than older versions did — genuinely backtracking and searching for a fully consistent set of versions across the whole tree, rather than simply installing the first compatible version found for each package independently and potentially producing an inconsistent result. This is why pip install can sometimes take real, noticeable time on a complex dependency tree: it's doing genuine constraint-satisfaction work, not just downloading files.

Understanding this resolution process demystifies pip's sometimes-confusing error messages — ERROR: Cannot install package-a and package-b because these package versions have conflicting dependencies is pip reporting that no single, consistent set of versions could be found across the entire tree, not a bug in pip itself, but a genuine incompatibility between the actual version constraints declared by the packages involved.

A requirements.txt file listing httpx>=0.27 (a version range, or even just httpx with no constraint at all) declares *acceptable* versions, not an exact, reproducible snapshot — exactly the range-versus-pin distinction covered generally in the Dependency Management lesson, now applied specifically to pip's own file format. Running pip install -r requirements.txt against that file at two different points in time can legitimately install two different actual sets of versions, as newer compatible releases become available on PyPI between those two install times.

A fully pinned requirements.txt — every package listed with an exact == version, including every transitive dependency, not just the direct ones you explicitly chose — behaves as a genuine, reproducible snapshot: pip install -r requirements.txt against that file installs the identical versions every time, on every machine, regardless of when it's run. Such a file is typically *generated*, not hand-written — tools like pip-compile (from pip-tools) or uv pip compile take a loose, human-written set of top-level dependencies and produce a fully pinned, reproducible lock file from them, mirroring the lock-file workflow covered generally in the Dependency Management lesson.

The practical convention many projects follow: a loose, human-maintained file (requirements.in, or dependencies declared directly in pyproject.toml) expressing genuine intent ('I need httpx 0.27 or newer'), and a separate, tool-generated, fully-pinned file (requirements.txt, or a proper lock file) that's what's actually installed in CI and production — exactly the same two-layer pattern (declared ranges plus a generated lock file) this curriculum has emphasized throughout its packaging coverage.

pip install -e . (covered from the project-structure angle in the Python Project Layout lesson) is, mechanically, pip performing an editable install — rather than copying your package's files into site-packages the way an ordinary install does, pip registers your package as installed while pointing back at your live source tree, so edits to source files take effect immediately without needing to reinstall. This is specifically a pip capability (implementing the PEP 660 editable-install standard, in modern versions), invoked identically regardless of which build backend (hatchling, setuptools) your pyproject.toml declares.

pip install -e ".[dev]" combines that editable install with an extras request — [dev] refers to a named group under [project.optional-dependencies] in pyproject.toml (covered in the pyproject.toml lesson), telling pip to install the base package plus everything declared in that specific extras group. Multiple extras groups can be requested together (".[dev,docs]"), and pip resolves the union of all requested groups' dependencies alongside the base package's own.

Understanding that pip install -e . and pip install package[extras] are both, fundamentally, pip performing its normal resolution-and-install process — just with an editable source pointer in one case, and an additional set of dependency groups in the other — demystifies these commands as extensions of the same underlying mechanism covered in the first section of this lesson, not separate, unrelated pip features to memorize independently.

pip install package is one command everyone runs constantly and few people can fully explain. Let's fix that.

pip install resolves version constraints across your ENTIRE dependency tree -- not just the one package you named.

Checkpoint: When you run pip install httpx, does pip only download and install httpx itself?

• →No — pip resolves and installs httpx's own dependencies too, finding versions satisfying every constraint across the whole tree
• →Yes — only the exact named package is installed; its dependencies must be installed separately

requirements.txt WITHOUT pinned versions is a range specification, not a reproducible snapshot -- exactly the drift problem from the Dependency Management lesson.

Checkpoint: Does a requirements.txt with "httpx>=0.27" (no upper bound, no exact pin) guarantee the same version installs every time it's used?

• →No — it's a range constraint, and a fresh install at a later date can resolve to a different, newer compatible version
• →Yes — pip always installs the exact same version for a given range on any machine

pip install -e . installs YOUR OWN package in editable mode -- covered in Project Layout, but pip is the tool actually doing it.

pip is the foundational installer; uv is the modern, dramatically faster reimplementation of the same core idea, worth knowing next.

Detect a Real Pinned Requirement. Finish is_pinned(): only == guarantees the exact same version every install.