Python Virtual Environments and Dependency Management

A virtual environment is an isolated Python installation that keeps one project's dependencies separate from every other project's dependencies, and separate from the system-wide Python installation. Without virtual environments, installing package versions for one project can silently break another project that needs a different, conflicting version of the same package — a problem often called "dependency hell."

Isolating dependencies per project also makes your work reproducible: anyone who clones your project can create an identical environment from a requirements file, rather than guessing which package versions you happened to have installed globally.

Why it matters

Two projects on one machine often need different versions of the same package, and installing everything into the system Python eventually breaks one of them. A virtual environment gives each project its own set of packages. Creating one is the first step in every real Python project, and it is assumed in every team and every deployment guide.

Creating and Activating a Virtual Environment with venv

Python includes the venv module in its standard library specifically for this purpose. Running python -m venv env creates a new directory named "env" containing a private copy of the Python interpreter and its own site-packages folder for installed libraries. You then "activate" it — on macOS/Linux with source env/bin/activate, on Windows with env\Scripts\activate — which changes your shell so that "python" and "pip" point to the environment's private copies instead of the system-wide ones. Deactivating with deactivate returns you to the system environment.

Installing Packages with pip

pip is Python's standard package installer, and it always installs into whichever Python environment is currently active. pip install requests downloads and installs the "requests" library and its dependencies from the Python Package Index (PyPI). pip install requests==2.31.0 pins an exact version, which matters for reproducibility since newer versions can introduce breaking changes.

requirements.txt

A requirements.txt file lists a project's dependencies, typically one package per line with an exact or minimum version, such as requests==2.31.0. Running pip freeze > requirements.txt captures everything currently installed in the active environment into this format, and pip install -r requirements.txt installs everything listed in the file in one command — this is exactly how a teammate or a deployment server recreates your environment reliably.

Example

# Create a virtual environment named "env"
python -m venv env

# Activate it (macOS/Linux)
source env/bin/activate

# Activate it (Windows)
env\Scripts\activate

# Install project dependencies into the isolated environment
pip install requests flask

# Record exact installed versions for reproducibility
pip freeze > requirements.txt

# Later, on another machine, recreate the same environment:
pip install -r requirements.txt

# requirements.txt contents after freeze, e.g.:
# flask==3.0.3
# requests==2.31.0
# (plus any transitive dependencies)

Exercise

Write the terminal commands, in order, to set up a new project: create a virtual environment named .venv, activate it, install the requests package, and save the list of installed packages to requirements.txt. These are shell commands, not Python code. Give the activation command for both Windows and macOS/Linux.

# 1. create the virtual environment

# 2. activate it (Windows PowerShell)
#    activate it (macOS / Linux)

# 3. install requests

# 4. save the installed packages to requirements.txt

# 1. create the virtual environment
python -m venv .venv

# 2. activate it (Windows PowerShell)
.venv\Scripts\Activate.ps1
#    activate it (macOS / Linux)
source .venv/bin/activate

# 3. install requests
pip install requests

# 4. save the installed packages to requirements.txt
pip freeze > requirements.txt

Quick quiz

Interview questions