Global packages cannot satisfy conflicting requirements. Virtual environments solve this problem.
A virtual environment is an isolated Python installation for a single project. It has its own site-packages directory. Packages installed in one environment do not affect others. You can have different versions of the same package in different environments.
This lesson covers creating and managing virtual environments with venv (built into Python 3.3+). You will learn to create environments, activate them, install packages, freeze requirements, and replicate environments on other machines.
🕯️ Magic Note
Virtual environments do not create full Python copies. They use symlinks or copies of the Python binary and create a separate site-packages directory. This makes them lightweight while providing full isolation.
- Isolate dependencies per project
- Avoid version conflicts between projects
- Test upgrades without breaking existing code
- Reproduce environments on different machines
- List project dependencies in requirements.txt
- Avoid permission issues (no sudo needed)
Bash
# Create a virtual environment named “venv” (common name)
python -m venv venv
# Create with a different name
python -m venv my_project_env
# Specify Python version (if multiple installed)
python3.11 -m venv venv
Bash (Linux / macOS)
# Activate
source venv/bin/activate
# Deactivate
deactivate
Command Prompt (Windows)
# Activate
venv\Scripts\activate
# Deactivate
deactivate
PowerShell (Windows)
# Activate
.\venv\Scripts\Activate.ps1
# Deactivate
deactivate
🕯️ Magic Note
When activated, your command prompt usually shows the environment name in parentheses, like (venv) user@host:~/project$. This indicates the environment is active.
Bash
# Activate environment first
source venv/bin/activate
# Install packages (installs into venv)
pip install requests
pip install flask==2.3.0
pip install “numpy>=1.20”
# See what’s installed
pip list
Bash
# After installing packages, freeze the environment
pip freeze > requirements.txt
# View the requirements file
cat requirements.txt
# requests==2.31.0
# flask==2.3.0
# …
🕯️ Magic Note
The requirements.txt file locks exact versions, ensuring everyone gets the same dependencies. This is critical for reproducibility.
Bash
# Create new environment
python -m venv venv
# Activate it
source venv/bin/activate
# Install from requirements file
pip install -r requirements.txt
Directory Structure Example
projects/
├── web_app/
│ ├── venv/ # Virtual environment for web app
│ ├── requirements.txt # Dependencies for web app
│ └── app.py
├── data_science/
│ ├── venv/ # Separate environment
│ ├── requirements.txt # numpy, pandas, etc.
│ └── analysis.ipynb
└── legacy_project/
├── venv/ # Old dependencies
├── requirements.txt # requests==2.25.0, etc.
└── main.py
.gitignore
# Virtual environments
venv/
.venv/
env/
.env/
ENV/
# Python cache
__pycache__/
*.pyc
# But DO commit requirements.txt
# requirements.txt
Bash
# Make sure it’s deactivated first
deactivate
# Delete the directory
rm -rf venv
Command Prompt (Windows)
# Deactivate first, then delete
rmdir /s venv
- VS Code: Ctrl+Shift+P → “Python: Select Interpreter” → Choose your venv
- PyCharm: Automatically detects venv when you open a project
- Jupyter: ipython kernel install –user –name=myenv
| Tool | Description | When to Use |
|---|---|---|
| venv | Built-in, simple | Most projects (default choice) |
| virtualenv | Older, more features | Python 2 compatibility (rare) |
| pipenv | Pipfile + Pipfile.lock | When you need deterministic builds |
| poetry | Dependency management + packaging | Professional libraries, complex dependencies |
| conda | Cross-language environments | Data science, scientific computing |
Bash
# 1. Create project directory
mkdir my_project
cd my_project
# 2. Create virtual environment
python -m venv venv
# 3. Activate it
source venv/bin/activate # On Windows: venv\Scripts\activate
# 4. Upgrade pip (optional but recommended)
pip install –upgrade pip
# 5. Install packages as needed
pip install requests
pip install flask
# 6. Freeze requirements when ready to share
pip freeze > requirements.txt
# 7. Write your code…
# 8. Deactivate when done
deactivate
- Forgetting to activate the environment (packages install globally)
- Committing the venv directory to Git
- Using different Python versions across team without specifying
- Not creating requirements.txt (others cannot reproduce)
- Running pip freeze without activating the environment (freezes wrong packages)
- How do you create a virtual environment named “myenv”?
- What command activates a virtual environment on Linux/macOS? On Windows?
- Why should you not commit the virtual environment to Git?
- How do you create a requirements.txt file from an active environment?
- How do you install packages from a requirements.txt file?
- What is the difference between venv and virtualenv?
⚡ Whisper
A virtual environment is your project’s private Python world. It has its own packages. Its own versions. Its own rules. Global Python stays untouched. Other projects stay untouched. Conflicts vanish. Reproducibility arrives. venv is built into Python. Use it for every project. Activate it. Install packages. Freeze requirements. Share with teammates. Deactivate when done. This is not optional. It is professional practice. A project without a virtual environment is a project waiting for a conflict. A requirements.txt file is documentation of what your code needs. Commit it. Share it. Recreate it. Your future self will thank you. Your teammates will thank you. The Python ecosystem is vast. Virtual environments make it manageable.
