On this page
The core idea
A virtual environment is a separate directory containing its own Python interpreter link and its own installed packages. Each project gets an environment, so upgrading a library for one project cannot silently break another. The environment itself is disposable: what matters is the record of dependencies, usually a requirements file or a pyproject.toml, that lets anyone rebuild the same setup. Treat the environment as a build output and the dependency file as source code.
A practical approach
Step 1
Create the environment inside the project with python -m venv .venv, and add .venv to .gitignore so it is never committed.
Step 2
Activate it before installing anything: source .venv/bin/activate on macOS and Linux, or .venv\Scripts\activate on Windows. Confirm with python -c "import sys; print(sys.prefix)" that the path points into the project.
Step 3
Install only what the project imports, then record it. For applications, pin exact versions with pip freeze > requirements.txt, or use a lock file from your tool of choice, so builds are repeatable.
Step 4
Rebuild from scratch to prove the record is complete: delete .venv, create a new environment, install from the dependency file and run the tests. Missing packages show up immediately.
Step 5
Point your editor at the project interpreter so linting, autocompletion and the debugger use the same packages as your terminal.
Worked example
A student has a Flask project from a course and starts a FastAPI project for a portfolio. Installing a newer version of a shared dependency for the second project breaks the first with an import error. Moving each project into its own .venv, generating a requirements.txt for each and reinstalling solves the conflict. When the student later moves to a new laptop, both projects are restored with two commands each instead of an afternoon of guessing versions.
A mistake to avoid
Do not use sudo pip install or install packages into the system Python on Linux or macOS. Operating system tools may depend on that interpreter, and changing its packages can break them in ways that are hard to trace back.
Try it yourself
Take one existing Python project, create a fresh virtual environment, install its dependencies from your notes and run it. Write down every package you had to add that was not recorded, then update the dependency file until a clean rebuild works first time.
Your implementation checklist
- Every project has its own virtual environment that is ignored by Git
- Dependencies are recorded in a file that is committed with the code
- A clean rebuild from the dependency file runs the project and its tests
- My editor uses the project's interpreter, not a global one
- No packages are installed into the system Python
Share or cite this guide
Innovate with Ajay Editorial (2026-10-07). Use Python Virtual Environments So Projects Stop Breaking Each Other. https://innovatewithajay.com/blogs/use-python-virtual-environments