pip's README is a short list of links, and the real constraints live in pyproject.toml

The README stops at two links and never shows a command

Open the pip README and the first thing you meet is three badges: the current version on PyPI, the Python versions PyPI shows for the project, and the state of the built documentation. After that comes a single definition. Pip is the package installer for Python, and you can use it to install packages from the Python Package Index and other indexes. Then the file does something unusual for an installer: it hands the two questions you actually arrived with, how to install it and how to use it, to two external pages named Installation and Usage, both under pip.pypa.io. Even the self description points outward, because the words package installer are themselves a hyperlink to the Python packaging recommendations on packaging.python.org. What is absent is the part a reader came for: no invocation, no flag name, no platform note, no error text, no troubleshooting. The consequence is plain. The README links to installation guidance, and the repository also contains the documentation sources. On a Raspberry Pi or a Windows machine, where the real question is which bootstrap path fits, the file offers nothing to compare, and the only evidence it hands you is a hyperlink.

The Python floor is set in two files, and only one of them is metadata

The packaging metadata puts a floor on the interpreter, and the comment above it is aimed at contributors rather than users.

# NOTE: requires-python is duplicated in __pip-runner__.py.
# When changing this value, please change the other copy as well.
requires-python = ">=3.10"

The note says requires-python is duplicated in __pip-runner__.py and that both copies must be changed together.

pip and pip3 are one entry point wearing two names

The console script table is three lines long and settles the naming question that confuses people most often. Two names are registered, and both resolve to the same function.

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

What the table leaves out matters as much as what it records. There is no interpreter, no version and no path. Two names pointing at one function looks tidy, but it means the name you type tells you nothing about the copy that answered. On a machine carrying several Python installations, pip can be one interpreter's copy and pip3 another's, both generated from this table when each was installed. The repository cannot arbitrate between them, and the README gives no procedure for checking. If you are about to trust an install list, pin down the interpreter that owns the pip on your PATH before you install anything, because after the fact this table offers you no way to tell the two apart.

The MIT grant does not cover the vendored trees under src/pip/_vendor

pip carries third-party code inside its own source tree, and its packaging metadata admits it. The license is MIT, and the file list beside it is not limited to the project's own paperwork.

license-files = [
  "AUTHORS.txt",
  "LICENSE.txt",
  "src/pip/_vendor/**/*COPYING*",
  "src/pip/_vendor/**/*LICENSE*",
]

Two of those four globs sit entirely under src/pip/_vendor, so a built distribution ships the licensing terms of every bundled dependency next to pip's own. The consequence for readers is concrete: an audit of what you are about to install cannot stop at the repository's LICENSE.txt. If your policy is to check licenses before a build pulls something into an environment, you have to walk the vendored tree as well, and this declaration is the map that tells you the tree is there. A second limit deserves naming: the PSF Code of Conduct that the README points to governs how people interact in codebases, issue trackers, chat rooms and mailing lists. It says nothing about what the vendored licenses permit, so conduct rules and license terms answer different questions here.

A release every three months, and none of them on the releases tab

The cadence is stated outright: updates come regularly, with a new version every 3 months. Two links carry the detail, a news page for release notes and a separate page describing the release process, and neither lives in the repository. The GitHub repository has no releases, so the releases tab is empty, and the version number is not written where you would look for it either, because pyproject.toml declares the version as dynamic. The checkout declares its source version in `src/pip/__init__.py`; that may differ from the version installed in your environment. Use `python -m pip --version` to inspect the selected interpreter’s installed pip, and check PyPI for published releases. What it does record is the support matrix in classifiers, Python 3.10 through 3.15, marked Development Status 5 Production/Stable and aimed at Developers under the Topic of Build Tools, plus the last push to the default branch main on 2026-11-02 with the repository not archived. Consult the in-tree changelog and published release notes to determine whether a fix is included in the version you use.

Three support routes the project does not control, and no security route at all

Support is spread across three systems, and the README hands you exact addresses for each. Bugs and help go to issue tracking on GitHub. General discussion goes to a Discourse channel at discuss.python.org/c/packaging. And there is a user IRC channel, reached through a kiwiirc nextclient link pointing at irc.libera.chat on port 6697, named pypa. Contributors are sent to a second channel on the same network, pypa-dev, along with the development documentation. What that arrangement cannot promise is continuity. Three of those routes sit on infrastructure the pip project does not own, and the file gives no fallback order, no statement about what happens if a channel closes, and no indication of which one is authoritative when the same question arrives in two places. The gap that bites hardest is security. Two files at the top of the repository, SECURITY.md and AI_POLICY.md, are linked nowhere in the README. A reader looking for the sanctioned way to report a vulnerability, starting from this file, finds no path and has to go hunting through the file list.

The test group pins pytest and leaves the 7.0 comment unattributed

The dependency group used for running the tests is the one place in the visible configuration that shows how the project is developed rather than shipped, and a single comment makes it ambiguous.

[dependency-groups]
test = [
    "cryptography",
    "flit-core >= 3.11, < 5",
    "freezegun",
    "installer",
    # pytest-subket requires 7.0+
    "pytest >= 7.0",
    "pytest-cov",
    "pytest-rerunfailures",
    "pytest-xdist",
    "pytest-subket",
]

The comment names pytest-subket and a 7.0 floor, yet it sits directly above the pytest requirement rather than above the pytest-subket entry. From the file alone a contributor cannot tell which package sets the floor, and guessing wrong costs time inside a resolver error instead of a clear message. The group also lists cryptography, freezegun, flit-core, installer and several further pytest plugins. Read the group as the declared test dependencies, not as the list of tools a contributor is expected to have running.

The documentation the README defers to is built from this tree, redirects and all

The top-level layout explains why the README can be so short and still be accurate. Source lives under src/, the test suite under tests/, documentation sources under docs/, changelog fragments under news/, and build and task tooling under tools/ and build-project/. The published documentation the README keeps sending you to is not a separate product: .readthedocs.yml at the root builds it, and .readthedocs-custom-redirects.yml sits beside it, which means the site handles moves for older URLs. That has a consequence for anyone chasing a stale link. A documentation address that has been redirected lands you somewhere the README never mentioned, and the published documentation URL identifies the documentation version, such as `stable`. One more file deserves a mention, because its absence from the README is conspicuous: NEWS.rst sits at the root next to the news directory, yet the changelog the project points you to is the hosted page under pip.pypa.io. Diffing changes means working out that the in-tree fragments and that page are two halves of one story.

Editorial conclusion

Use this repository when you are working on pip itself or auditing what a build will pull into an environment, and use the hosted documentation when you want an answer tonight. The checkout is honest about what it is, a code and metadata tree rather than a guide, and it is current: the default branch main was pushed on 2026-11-02 and the project is not archived. Before you rely on it, settle three things the repository leaves open. Which pip your PATH resolves to, since the entry point table registers pip and pip3 with no interpreter or version attached. Which version you are running: use `python -m pip --version` for the selected interpreter. The source version is declared in `src/pip/__init__.py`, while published versions are listed on PyPI. And where the sanctioned security contact lives, since SECURITY.md sits in the tree and appears nowhere in the README.

Frequently asked questions

Official sources

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