What does pip cache locally, and what does `--no-cache-dir` trade away?

### Two caches under one directory pip maintains a per-user cache directory — its location is platform-specific and `pip cache dir` prints it. Inside are two distinct things that people usually merge into one word. **The HTTP cache.** Responses from the index and the distribution files pip downloaded, cached according to HTTP semantics. A repeat install of the same wheel does not re-download it. This is what makes reinstalling into a fresh environment noticeably faster than the first time even when nothing is built. **The wheel cache.** When pip must *build* a wheel — the distribution is published only as a source distribution, or only an sdist matches the platform — it stores the wheel it produced and reuses it for later installs of the same source. That is the expensive half. Building a package with a compiled extension means running a compiler over C or C++ sources; a cached wheel turns a multi-minute build into an unzip. For a version-control target the cached entry is keyed on the resolved commit, which is another reason to pin a commit rather than a branch. Builds of a **local project directory** are deliberately not cached: the directory is mutable, so there is no honest key to store the result under. ### What `--no-cache-dir` changes The flag disables both reading and writing, for that invocation. pip downloads what it needs, builds what it must, installs, and leaves nothing behind. The usual reason is image size. In a container image built layer by layer, an install that populates the cache writes those files into the layer, where they are dead weight — the image ships wheels and archives it will never install again, sometimes hundreds of megabytes of them, and deleting them in a later layer does not shrink the image because the earlier layer still contains them. Passing `--no-cache-dir` in the install step is the simple fix; a build-tool cache mount that keeps the cache outside the layer is the sophisticated one, and gives you both speed and size. The cost is straightforward: every rebuild re-downloads and re-builds. For a fraud-scoring service whose image is rebuilt before each nightly six-hour run, that can turn a thirty-second install into several minutes of compiling the same sources again — every night, forever. Whether that matters depends on how often you build and what is in the dependency set, which is exactly the tradeoff the question is testing. ### CI, where the answer inverts A CI runner that starts from a clean filesystem repeats the entire download-and-build every job. Restoring the pip cache directory from the job cache, keyed on the requirements file's contents, is one of the highest-value build optimisations available, and it is invisible to the application. The rule of thumb: **cache where the directory survives and the artifact does not** (CI runners, developer machines), **disable where the artifact survives and carries whatever you wrote** (image layers). ### Correctness questions people raise *Can a stale cache install the wrong thing?* Cache entries are keyed on the distribution file and, for built wheels, on the source and the build context, so a different version is a different entry. The failure mode is not usually a wrong package but a build that no longer matches the machine — a wheel built against a system library that has since changed. When you suspect that, purge the cache rather than debugging it; a full purge costs only the time to rebuild. *Does the cache replace an index?* No. pip still contacts the index to learn which versions exist and resolve them, unless you also pass `--no-index`. A populated cache does not make an install work offline; a directory of wheels with `--find-links` does. *Does it help a locked, hash-pinned install?* Yes, and safely: the recorded hash is checked against the file whether it came from the network or the cache, so caching is a pure speed-up rather than a trust decision. ### The answer to give Name both caches, say that the wheel cache is the one that saves real time because it skips a build, and then give the tradeoff as a place rather than a preference: keep it where the directory outlives the install, disable it where the filesystem becomes the artifact you ship.