Virtual Environments & pip — Isolating Every Project
Beginnerpython -m venv .venv gives each project its own interpreter and packages; pip installs into it; requirements.txt with pinned versions makes the setup reproducible on any machine.
Overview
Installing packages globally is how projects break each other: project A needs Django 4, project B needs Django 5, and the second install silently breaks the first. A virtual environment is a per-project folder containing a private Python and site-packages; activate it and pip installs land there and nowhere else. The workflow is muscle memory after a week: create .venv, activate, pip install, freeze to requirements.txt, commit that file (never the .venv folder itself). Every serious Python repo you clone — including every FastAPI service — expects this dance, and CI/CD pipelines and Dockerfiles run the same pip install -r requirements.txt.
The Daily Workflow
One environment per project, created once, activated every session. The (.venv) prefix in your prompt confirms which environment is live; python and pip now refer to the project-local copies.
# Create (once per project, inside the project folder)
python -m venv .venv
# Activate (every new terminal session)
.venv\Scripts\activate # Windows
source .venv/bin/activate # macOS / Linux
# prompt becomes: (.venv) C:\projects\campus-api>
# Install packages — they go into .venv only
pip install requests "fastapi[standard]" sqlalchemy
pip list # what is installed here
pip show requests # version, dependencies, location
# Leave the environment
deactivate
# .gitignore MUST contain:
# .venv/requirements.txt — Reproducible Installs
pip freeze snapshots exact versions so a teammate, the CI runner, and the production Docker image all install identical packages. Pin versions for applications; loose ranges belong in libraries, not deployed apps.
# Snapshot the current environment
pip freeze > requirements.txt
# requests==2.32.3
# fastapi==0.115.6
# sqlalchemy==2.0.36
# ...
# Anyone (or any CI job / Dockerfile) reproduces it:
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
# Upgrading deliberately (not accidentally):
pip install --upgrade fastapi
pip freeze > requirements.txt # re-snapshot after verifying
# Modern alternative worth knowing: uv (Rust-based, 10-100x faster)
# uv venv && uv pip install -r requirements.txt
# Same concepts, drastically faster resolver — common in 2025+ repos.Key Points to Remember
- 1One venv per project; global installs are how projects break each other
- 2Activate first — then python/pip mean the project-local copies
- 3pip freeze > requirements.txt pins exact versions; commit the file, ignore .venv/
- 4Same requirements.txt drives teammates, CI, and Docker builds; uv is the fast modern drop-in
Interview Questions
Sign in to ask AriaWhy do virtual environments exist? What breaks without them?
Difference between pip freeze and just listing top-level dependencies?
Your app works locally but crashes in Docker with an import error. Walk through your debugging.
Ask Aria about Virtual Environments & pip — Isolating Every Project
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.