← all cheat sheets
FUNDAMENTALS · MECHANISM WALKTHROUGH

pip install Inside a Virtualenv
What Really Happens, Step by Step

why the same command installs to a completely different place depending on one thing: whether a venv is active.
ACTIVATE VENV RESOLVE DEPENDENCIES QUERY PyPI INDEX DOWNLOAD WHEEL BUILD (IF NEEDED) INSTALL TO site-packages METADATA WRITTEN
01 The Full Sequence — Worked Example
1

Activating the venv Rewrites PATH

source .venv/bin/activate doesn't do anything magical — it just prepends .venv/bin to your shell's PATH, so the next time you type python or pip, the shell finds the venv's copies first.

Activate
2

pip Is Now the Venv's Own Copy

Every venv gets its own pip binary at creation time, pointed at its own site-packages directory. This is why "pip install" behaves completely differently depending on activation — it's literally a different pip executable, not a mode switch.

Isolation
3

pip Parses the Request & Existing Constraints

For pip install requests, pip reads any version constraint given, checks what's already installed in this venv, and begins building a dependency resolution problem — requests itself depends on urllib3, certifi, charset-normalizer, idna.

Resolve
4

Checkpoint — Nothing Downloaded Yet

The resolver's job is to find a single set of package versions that satisfies every constraint simultaneously — requests' pin on urllib3, any pin in your own requirements.txt, etc. — before a single byte is downloaded.

Checkpoint
5

Query the Package Index (PyPI)

pip queries pypi.org (or a configured private index/mirror) for available versions and metadata of each required package, over HTTPS.

Index
6

Download the Wheel (Preferred) or Sdist

pip prefers a prebuilt wheel (.whl) matching your Python version/OS/architecture — no compilation needed. If no matching wheel exists, it falls back to a source distribution (sdist) that must be built locally.

Download
7

Build Step (Only for Source Distributions)

If a wheel wasn't available, pip invokes the package's build backend (commonly setuptools) to compile it locally — this is where missing system libraries or a missing C compiler cause install failures that a wheel would have avoided entirely.

Build
8

Files Copied into site-packages

The package's actual Python files are unpacked into .venv/lib/python3.x/site-packages/ — this is precisely the directory that ends up on sys.path for anything run inside the activated venv.

Install
9

Metadata (RECORD, dist-info) Written

pip writes a *.dist-info directory recording exactly which files were installed and the package version — this is what makes pip uninstall and pip list reliable later.

Metadata
10

Without an Active venv — Global Install

Run the identical command with no venv activated, and PATH resolves to the system pip instead — installing into the global/user site-packages, potentially affecting every other project (or requiring sudo, or being blocked by an externally-managed-environment guard on modern distros).

Global Path
02 How to Explain This in an Interview
03 Follow-Up / Gotcha Questions
Q If I deactivate the venv, does the installed package disappear?
A No — the files remain on disk inside .venv/lib/.../site-packages exactly as installed. Deactivating just changes PATH back, so a plain "python" outside the venv no longer sees them, but they're not deleted.
Q Why does pip install sometimes need a C compiler and sometimes not?
A Only when no prebuilt wheel matches your Python version/OS/architecture combination — then pip falls back to building from source, which for C-extension packages (like some cryptography or database drivers) requires a compiler and headers.
Q Two projects need different versions of the same package — how does this actually get solved?
A It doesn't get solved within one environment — each project needs its own venv. A single site-packages directory can only hold one version of a given package at a time; that's precisely the isolation problem venvs exist to solve.
Q What does requirements.txt actually pin, and does pip re-resolve every time?
A requirements.txt is just a list of constraints fed into the same resolver described above — pip re-runs resolution every install unless you use a fully pinned/hashed lockfile, so unpinned transitive dependencies can still drift between installs.
Q Does pip verify the downloaded package hasn't been tampered with?
A By default it trusts PyPI's TLS and package hash metadata; for stronger guarantees you'd add --require-hashes with a fully pinned requirements file listing exact SHA256 hashes.
Q Why might "pip install X" succeed but "import X" fail right after?
A Usually a python/pip mismatch — pip installed into one interpreter's site-packages while a different python (a different PATH entry or venv) is being used to run the import.
04 Quick-Fire Glossary
TermMeaning
venvAn isolated Python environment with its own interpreter symlink, pip, and site-packages
PATHOrdered list of directories the shell searches to resolve a command name
Wheel (.whl)Prebuilt, ready-to-install package format — no local compilation needed
SdistSource distribution — must be built locally if no matching wheel exists
site-packagesThe directory inside a venv (or global install) where installed packages live
Resolverpip's component that finds a version set satisfying all dependency constraints
dist-infoMetadata directory pip writes per package, recording installed files & version
requirements.txtA plain list of version constraints fed into the resolver on install
PyPIThe default public package index pip queries (pypi.org)
externally-managed-environmentModern Linux guard blocking global pip installs outside a venv