I know, I know. Setting up a venv sounds like extra work. One more step before you can finally start writing code. But trust me — anyone who has wrecked their system Python once sets up a virtual environment for every project afterwards. No exceptions.
What happens without a venv
Python installs packages globally. Genuinely globally, for the whole machine. Project A needs Django 4.2, project B only runs on Django 3.2 — and now you have a problem. Pip installs whichever version you asked for and the old one is gone. No warning, no backup.
It gets particularly annoying with dependencies of dependencies. Package X needs requests 2.28, package Y needs requests 2.31. Without isolation Python resolves that somehow in the best case, and everything falls over in the worst.
A venv in 30 seconds
It really is not complicated:
python -m venv .venv
# Linux / macOS
source .venv/bin/activate
# Windows (PowerShell)
.venv\Scripts\Activate.ps1
# Windows (cmd)
.venv\Scripts\activate.bat
After that you live in a bubble. pip install only affects this project. Want out? deactivate. That is the whole thing.
One detail many people do not know: .venv is only a naming convention. You can call the folder whatever you like. But .venv has become the default and most editors detect it automatically. VS Code, for example, finds the environment and offers it as the interpreter.
Do not forget requirements.txt
Installed everything? Then write it down:
pip freeze > requirements.txt
And on another machine, or after a reset:
pip install -r requirements.txt
That is the absolute minimum standard. Anyone working in a team without a requirements.txt will produce the classic works-on-my-machine problem sooner or later.
Alternatives: Poetry, Pipenv, uv
They exist, of course. Poetry handles dependencies and packaging in one tool. Pipenv was the hot tip once and has faded somewhat since. And uv from Astral — the newcomer, absurdly fast, but still young.
For most projects venv is entirely sufficient. You do not have to try every tool that happens to be trending. Solid fundamentals beat a fancy toolchain.
Typical traps
Number one: forgetting to activate the environment. You cheerfully install packages, then wonder why they are not available in the project — because they landed globally. The shell normally shows (.venv) at the start of the line when the environment is active.
Number two: pushing the .venv folder into the Git repository. That belongs in .gitignore. Always. The folder is operating-system specific and can run to several hundred megabytes.
Number three: the Python version inside the venv. A venv uses the Python version it was created with. If you have both 3.11 and 3.12 installed, pay attention to which one you point at when creating it.
The short version
A venv is three seconds of setup and saves hours of debugging. There is no sensible reason not to use one. Full stop.