Why Virtual Environments?

If you ever wonder "why do I need python3 -m venv venv?" — this page explains it.

The Problem

Imagine you have two Python projects:

Project A: needs Flask version 2.0
Project B: needs Flask version 3.0

Without virtual environments, Python installs packages globally. Installing Flask 3.0 would break Project A.

The Solution

Each project gets its own isolated environment with its own packages:

System Python
├── Project A (venv) → Flask 2.0
├── Project B (venv) → Flask 3.0
└── Other projects (no venv) → whatever system has

How It Works

# Create a virtual environment
python3 -m venv venv

# Activate it
source venv/bin/activate      # macOS/Linux
venv\Scripts\activate         # Windows

# Now pip installs go into venv/, not system-wide
pip install flask

# When done, deactivate
deactivate

After activation, your terminal shows (venv) at the prompt — a visual reminder.

What's Inside a Virtual Environment?

venv/
├── bin/          # Python executable + scripts
├── lib/          # Installed packages live here
└── pyvenv.cfg    # Points to the system Python it was created from

When activated, python3 runs the one inside venv/bin/, and it only sees packages installed in venv/lib/.

The `.gitignore` Rule

Never commit your virtual environment. Add it to .gitignore:

echo "venv/" >> .gitignore

Other developers recreate it from requirements.txt:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Quick Analogy

Think of a virtual environment like a backpack. Instead of carrying every tool you own everywhere (global install), you pack only what you need for the current hike (project). When you switch hikes, you repack.

← Read Errors Debugging →