A virtual environment isolates your packages, but it lives only on your machine. When someone else clones your project — or you set it up on a new laptop — they need to know what to install.

requirements.txt is that list.

requests==2.31.0
beautifulsoup4==4.12.2
pytest==7.4.3

One package per line. Commit this file; never commit .venv/.

Generating it

pip freeze > requirements.txt

pip freeze prints everything installed with exact versions; > writes that to the file.

Installing from it

pip install -r requirements.txt

-r means "read the list from this file." This is the first command anyone runs after cloning your project — usually right after creating and activating a venv.

The full setup for a new contributor:

git clone https://github.com/someone/project.git
cd project
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Version specifiers

| Line | Means | | --- | --- | | requests | any version — avoid | | requests==2.31.0 | exactly this version | | requests>=2.28 | this or newer | | requests>=2.28,<3.0 | this or newer, but not 3.x | | requests~=2.31.0 | 2.31.x, no minor bumps |

Pin exact versions (==) for applications. You want the code that ships to be the code you tested. Unpinned dependencies mean the app can break because a library released an update — and it breaks for new contributors first, which is a miserable way to start.

Use ranges (>=2.28,<3.0) for libraries you publish, so other people's projects can share one compatible copy.

The pip freeze catch

pip freeze records everything installed, including sub-dependencies you never asked for:

requests==2.31.0
charset-normalizer==3.3.2
idna==3.6
urllib3==2.1.0
certifi==2023.11.17

Only requests was your decision — the rest came along with it. That's fine for a reproducible application, but it obscures your actual intent, and removing a package leaves orphans behind.

A common approach is to hand-write the file with just your direct dependencies, and let pip resolve the rest. Tools like pip-tools and poetry formalise this by keeping a short "what I want" file separate from a fully-pinned lock file.

Related files you'll see

• requirements-dev.txt — testing and linting tools, not needed to run the app
• pyproject.toml — the modern standard, holding dependencies plus project metadata
• poetry.lock / uv.lock — fully-pinned lock files generated by those tools

requirements.txt is still the most widely understood, and the right thing to learn first.

Try it yourself

Write and parse a requirements.txt — it's just a text file, so Module 6 skills apply.

Checkpoint

• requirements.txt lists what to install; commit it, never commit .venv/.
• pip freeze > requirements.txt generates it; pip install -r requirements.txt installs it.
• Pin exact versions for applications; use ranges for published libraries.
• pip freeze includes sub-dependencies, which hides your real intent.
• pyproject.toml and lock files are the modern evolution of the same idea.