Virtual Environments & requirements.txt

Why isolate?

When you pip install a package, by default it goes into one shared place for your whole computer. That causes trouble: Project A might need version 1 of a library while Project B needs version 2 — they cannot both be installed globally. A virtual environment solves this by giving each project its own private folder of packages, completely separate from every other project and from the system Python.

Think of it like giving each project its own toolbox instead of everyone sharing one messy drawer. The word dependency just means “a package your project needs to run.”

Create and activate one

Python ships with a tool called venv to make these environments. You run it once per project, in the project’s folder. You do this in the terminal, not inside a Python file.

# 1. create a virtual environment named "venv"
python -m venv venv

# 2. activate it
#   Windows:
venv\Scripts\activate
#   Mac / Linux:
source venv/bin/activate

Here is what each step does, in order:

1. python -m venv venv creates a new folder (named venv) holding a private copy of Python and an empty package area just for this project.
2. The activate command switches your terminal to use that private environment. You will see (venv) appear at the start of your prompt — that is how you know it is on.
3. While active, every pip install now installs into this project only, leaving your system and other projects untouched.
4. When you are done, type deactivate to leave and return to the normal system Python.

requirements.txt: a shopping list of packages

Once your project uses a few packages, you need a way to record exactly which ones (and which versions) so anyone — including future you — can recreate the same setup. That record is a plain text file called requirements.txt. Two commands handle it:

# save the current environment's packages to a file
pip freeze > requirements.txt

# later, on another machine, install them all at once
pip install -r requirements.txt

pip freeze lists every installed package with its exact version, and > requirements.txt saves that list into the file. The file looks like requests==2.32.3, one package per line. Later, pip install -r requirements.txt reads that file and installs everything in it in one go — so a teammate (or a server) gets the identical set of packages. This file is what you commit to Git so the project is reproducible.