Virtual environments — venv, pip, requirements.txt
WHY do virtual environments exist?
The three things venv isolates:
- Packages — each env has its own
site-packages. - Python interpreter link — each env points to a specific Python version.
pip/scripts — installed command-line tools live inside the env.
WHAT exactly is a venv? (Derivation from first principles)
When Python starts, it builds a list of folders to search for imports, called sys.path. The key insight:
HOW to use it — the full workflow
Worked Example 1 — Build a fresh project
mkdir weather && cd weather
python -m venv .venv
source .venv/bin/activate
pip install requests
pip freeze > requirements.txt| Step | Why this step? |
|---|---|
mkdir weather |
One folder = one project = one env. Keeps things clean. |
python -m venv .venv |
Creates the isolated interpreter. .venv is the conventional hidden name. |
source .venv/bin/activate |
Now which python → weather/.venv/bin/python, so installs land here. |
pip install requests |
Goes into .venv/lib/.../site-packages, not system Python. |
pip freeze > requirements.txt |
Records requests==2.32.3 (+ its dependencies) so a teammate can reproduce. |
Worked Example 2 — Reproduce a teammate's project
git clone https://example/cool-app && cd cool-app
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt| Step | Why this step? |
|---|---|
git clone |
You get the code and requirements.txt, but not the env (it's gitignored). |
python -m venv .venv |
The env is local & disposable — rebuild it, don't ship it. |
pip install -r requirements.txt |
Re-creates the exact package set the author used. Same versions = same behaviour. |
Worked Example 3 — freeze vs hand-written requirements
# pip freeze output (fully pinned, machine-generated)
flask==3.0.3
requests==2.32.3
certifi==2024.7.4 # ← transitive dependency, auto-included
# hand-written (loose, human-curated)
flask>=3.0
requests| Style | Why use it? |
|---|---|
== pins (from freeze) |
Reproducible builds — production, sharing exact state. |
>= / unpinned |
Libraries, where you want users to get compatible newer versions. |
Common mistakes (Steel-manned)
Recall Feynman: explain it to a 12-year-old
Think of your computer's Python like one shared toy box for the whole house. If your big brother fills it with race-car parts and you need doll parts, you fight over the same box. A virtual environment is like giving each kid their own little box with only their toys. python -m venv makes a new empty box. pip install puts toys in your box only. requirements.txt is a shopping list so if your box gets lost, you can buy exactly the same toys again. And activate just means "open my box and use it right now".
Active-recall flashcards
What problem do virtual environments solve?
What command creates a venv in folder .venv?
python -m venv .venvWhy use python -m venv instead of venv?
-m runs the venv module with that specific Python, fixing which interpreter version the env uses.What does activating a venv actually do under the hood?
PATH so python and pip point to the env's copies, redirecting installs into the env's site-packages.How do you save your env's exact packages to a file?
pip freeze > requirements.txtHow do you rebuild an env from that file?
pip install -r requirements.txtShould .venv/ be committed to git?
requirements.txt instead (the env is reproducible, OS-specific, and large).Does activation persist across terminal windows?
What's the difference between flask==3.0.3 and flask>=3.0 in requirements?
== pins an exact version (reproducible builds); >= allows compatible newer versions (libraries).How do you leave an active environment?
deactivate.What appears in your prompt when an env is active?
(.venv).What is site-packages?
Connections
- pip and PyPI
- Python import system and sys.path
- Dependency management — poetry, pipenv
- Reproducible builds and Docker
- .gitignore best practices
- Semantic versioning
Concept Map
Hinglish (regional understanding)
Intuition Hinglish mein samjho
Socho tumhare laptop pe do projects hain. Project A ko Django 3.2 chahiye aur Project B ko Django 4.2. Agar tum sab kuch globally (system Python me) install karoge, to ek time pe sirf ek hi version reh sakta hai — ek install karoge to doosra project toot jayega. Isi mess ko bolte hain "dependency hell". Virtual environment isi problem ka solution hai: har project ko apna alag chhota Python + packages ka dabba milta hai, jo kisi aur project ko disturb nahi karta.
Kaam kaise karta hai? python -m venv .venv ek folder banata hai jisme ek mini Python launcher aur ek khaali site-packages hota hai. Jab tum activate karte ho, tumhare shell ka PATH change ho jata hai — ab python aur pip typing karne pe wahi env wala chalta hai. Matlab koi magic nahi, bas PATH ka jugaad. Iske baad jo bhi pip install karoge, woh sirf is env ke andar jayega, system me nahi.
requirements.txt ek shopping list hai. pip freeze > requirements.txt se tumhare exact versions us file me save ho jate hain. Dusra banda ya dusra computer pip install -r requirements.txt chalakar bilkul wahi packages laga sakta hai — isliye "mere yahan to chal raha tha" wali problem khatam. Yaad rakho: .venv/ folder ko git me kabhi commit mat karo (woh bada aur OS-specific hota hai), sirf requirements.txt commit karo.
Sabse common galti: log bhul jate hain ki activate sirf current terminal ke liye hota hai. Naya terminal khola to dobara source .venv/bin/activate karna padega. Hamesha prompt me (.venv) dekh lo install karne se pehle — yeh chhoti aadat tumhe ghante bachayegi.