Python virtual environments isolate project dependencies from each other and from the system Python — essential practice for any serious Python deployment, avoiding dependency conflicts between projects.
Why Virtual Environments Matter
Without isolation, installing packages globally means every project shares the same dependency versions — if Project A needs version 1.0 of a library and Project B needs version 2.0, a global installation can't satisfy both simultaneously; virtual environments solve this by giving each project its own isolated dependency set.
Creating a Virtual Environment
python3 -m venv venvCreates a venv directory containing an isolated Python environment specific to this project.
Activating the Virtual Environment
source venv/bin/activateYour shell prompt typically changes to indicate the active virtual environment — any pip install commands now install into this isolated environment, not system-wide.
Installing Packages Within the Virtual Environment
pip install requests flaskSaving Dependencies to requirements.txt
pip freeze > requirements.txtCaptures exact installed versions, letting others (or your production server) recreate the identical environment.
Installing from requirements.txt
pip install -r requirements.txtDeactivating the Virtual Environment
deactivateReturns to your normal shell environment, no longer using the isolated Python/packages.
Never Commit the venv Directory to Version Control
echo "venv/" >> .gitignoreVirtual environments are environment-specific and can be large — commit only requirements.txt, letting anyone recreate the environment themselves rather than committing the actual environment directory.
Using Virtual Environments in Production Deployment
python3 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activate
pip install -r requirements.txtYour production server should also use a dedicated virtual environment, not install dependencies globally — keeps your deployment consistent with development and avoids any system-level Python conflicts.
Referencing the Virtual Environment in systemd Services
ExecStart=/opt/myapp/venv/bin/gunicorn myapp:appPoint directly at the virtual environment's specific binary path, ensuring the service uses the correct isolated Python/dependencies rather than accidentally using system Python.
Combining with pyenv for Version + Dependency Management
See How to Manage Multiple Python Versions with pyenv — use pyenv to select the correct Python version, then create a virtual environment using that specific version, giving you full control over both Python version and package isolation.
Alternative Tools: Poetry and pipenv
Beyond the built-in venv module, tools like Poetry and pipenv offer additional dependency management features (better dependency resolution, integrated lock files) — worth exploring for more complex projects, though venv alone is entirely sufficient for most straightforward deployments.
Common Errors
"command not found" for a package's CLI tool after installing in a venv — verify the virtual environment is actually activated (or you're referencing its binary path directly); the tool exists only within the isolated environment, not system-wide.
Continue Reading
- How to Manage Multiple Python Versions with pyenv
- How to Deploy a Django/Flask Application with Gunicorn and Nginx
- How to Audit and Secure Your Application's Dependencies
Browse more articles in Programming Languages & Runtimes.
