Definition
Typing pip install requests assumes that somewhere, a file named requests already exists, ready to be fetched. PyPI is that place: the public repository where Python developers publish their libraries, and the one Python checks by default on every installation. Without it, every project would have to rewrite its own code instead of building on someone else's.
PyPI, short for the Python Package Index, looks less like a shop than a library catalogue: one page per project, one downloadable archive per version, and nothing more. It does not run, does not install itself and knows nothing about your projects, it only answers the download requests sent to it.
Here is what that answer looks like, concretely, once the command succeeds.
pip install requests
# Downloading requests-2.32.3-py3-none-any.whlThe file name printed there, requests-2.32.3-py3-none-any.whl, is the one PyPI just served. But it is pip that downloads that file and installs it on disk: PyPI only makes it available. That distinction matters the day an installation fails.
PyPI, pip and where things land
When an installation fails, the instinct is to blame PyPI. That is rarely where the problem sits. PyPI, pip and the virtual environment stand for three separate things, and mixing one up with another sends the search to the wrong place.
The table below separates what each one actually does, so you know which one to question first.
| Name | Role | Where it lives |
|---|---|---|
| PyPI | Hosts and serves every published package | Online |
pip | Downloads, resolves dependencies, installs | On the machine |
| virtual environment | Receives the installed files | Inside the project |
A failed installation almost always comes from the second or third row, rarely the first: the repository answered correctly, but the environment active at the moment of the command was not the one anyone thought.
What a project page lets you judge
Before installing anything, one question inevitably comes up: does this library hold up, or is it an abandoned project about to be dragged along as dead weight? A PyPI project page does not answer that directly, but it offers four signals that, taken together, settle the question without reading a single line of code.
Here is what each of those signals actually reveals, once you know where to look.
| What to look at | What it reveals |
|---|---|
| Date of the latest version | A maintained project, or one dropped four years ago |
| Number of versions | A single release means zero published fix |
| Link to the source code | Missing, there is nothing to read before installing |
| Licence | What commercial use actually allows |
None of this guarantees the quality of the code. But together, it sketches a level of seriousness that reads in thirty seconds: a library kept up to date for eight years does not get mistaken for a project uploaded one evening and never touched again.
Anyone can publish, and names mislead
Publishing on PyPI requires no particular skill and no review by anyone: create an account, upload an archive, and the package becomes available to the whole world within the minute. That openness explains the size of the catalogue, but also its one serious danger.
A package named one letter away from a well known library counts on a typo to get installed in its place. Copying the name from the official documentation, rather than typing it from memory, removes most of that risk.
The second trap has nothing to do with security and everything to do with naming: the name you install is not always the one an import expects right after. The table below shows the cases that come up most often.
| Name to install | Name to import |
|---|---|
| pillow | PIL |
| beautifulsoup4 | bs4 |
| scikit-learn | sklearn |
| python-dateutil | dateutil |
This is the source of the most baffling ModuleNotFoundError of all: the one that shows up right after an installation that just succeeded, visibly, in front of the reader.
When PyPI is of no use
Before typing an install command, another question is worth asking: does Python not already handle this on its own? A good share of everyday needs is already covered by the standard library, shipped with the interpreter and therefore absent from any installation. Handling file paths with pathlib, dates with datetime, json or execution logs requires no download at all. Reaching for a package there only adds a dependency to maintain, for nothing gained in return.
Two other situations step outside the public repository. A company can host its own libraries on an internal index, invisible from the outside. And a machine with no network access installs from archives copied by hand, following the list laid out in a requirements.txt.
Frequently asked questions
Is a PyPI account needed to install a library?
No. Browsing and downloading are public and anonymous, and no sign-up is asked for. The account only becomes necessary to publish a project yourself, and it then requires two-factor authentication.
How can anyone tell whether a package is still maintained?
The date of the latest version gives the first answer, and the rhythm of the previous ones confirms it. A project released every three months for five years, then silent for the last two, is abandoned, whatever its star count.
Does PyPI host tools as well, and not only libraries?
Yes. Formatters, static analysers, project managers such as poetry and web frameworks are published there in exactly the same way. A package can provide a command to run, a module to import, or both at once.