Every Python developer eventually learns this lesson the hard way: install enough packages globally and sooner or later two projects need conflicting versions of the same library, and everything breaks. Python virtual environments are the fix, and they are simple enough that there is no excuse not to use one for every project.
What a virtual environment actually is
A virtual environment is just an isolated folder containing its own Python interpreter and its own set of installed packages. When it is active, pip install puts packages there instead of in your system Python. Delete the folder and the project’s dependencies vanish cleanly, with nothing left polluting the rest of your machine.
Creating and activating one
Python ships with venv built in, so you need nothing extra:
# Create it (the second "venv" is just the folder name)
python -m venv venv
# Activate it
source venv/bin/activate # macOS / Linux
venv\Scripts\activate # Windows
# Your prompt now shows (venv)
pip install requestsWhile it is active, python and pip point at the isolated environment. When you are done, type deactivate to step back out.
Locking your dependencies
An environment is only reproducible if you record what is in it. That is what a requirements file is for:
# Save the current packages
pip freeze > requirements.txt
# Recreate them elsewhere
pip install -r requirements.txtCommit requirements.txt to your repository, but never commit the venv folder itself — add it to .gitignore. The folder is large, machine-specific, and trivially rebuilt from the requirements file.
Why it matters more than it seems
Beyond avoiding version clashes, virtual environments make your projects portable and your bugs reproducible. When a teammate can recreate your exact dependency set in one command, “works on my machine” stops being an argument. And when a deployment uses the same locked versions as your laptop, a whole category of surprise failures disappears.
A quick word on the alternatives
You will hear about tools like virtualenv, pipenv, poetry, and conda. They add features — nicer dependency resolution, lock files, environment management — but they all rest on the same core idea you just learned. Start with the built-in venv, get comfortable, and graduate to a heavier tool only when a real need appears.
Make creating a virtual environment the first thing you do in any new project. It takes ten seconds and saves you hours of dependency archaeology later. Python virtual environments are not advanced — they are table stakes for writing Python you can trust.
