Python VirtualEnv
Python · Tooling & Errors
Theory
A virtual environment is a self-contained folder with its own Python interpreter link and its own set of installed packages, separate from the system Python and from other projects. python -m venv .venv creates one; activating it (source .venv/bin/activate on macOS/Linux, .venv\Scripts\activate on Windows) makes python and pip in that terminal point to it.
After activation, pip install pandas installs pandas only into .venv. Project A can use one version of a library and project B another without conflict. deactivate returns to the global Python. The usual workflow is: create the venv, activate it, install packages, save them with pip freeze > requirements.txt, and add .venv to .gitignore so the folder itself is never committed.
Why we use it
Different projects need different package versions, and installing everything globally eventually breaks something. A virtual environment keeps each project's dependencies isolated and reproducible.
When to use it
Create one for every real project, before installing packages. Only throwaway experiments can skip it. conda environments or tools like poetry and uv offer the same isolation with extra features.
How it works
- Start a new project folder
- python -m venv .venv
- Activate the environment
- pip install the packages you need
- pip freeze > requirements.txt
- Done working? Yes: Run deactivate. No: Keep coding inside the venv.
- Project dependencies stay isolated
Syntax
python -m venv env_name
source env_name/bin/activateExample
python -m venv .venv
source .venv/bin/activate
pip install pandasKey points
- Prevents dependency conflicts between projects
- Each project can pin its own package versions
- Activate before installing, or packages go to the wrong place
- Do not commit the .venv folder - commit requirements.txt
- deactivate leaves the environment