A virtual environment gives a project its own interpreter context and installed packages. It prevents one project’s dependencies from silently changing another project.Copy
python -m venv .venv
# Windows PowerShell
.venv\Scripts\Activate.ps1
# macOS/Linux
source .venv/bin/activate
python -m pip install --upgrade pipInstall project dependencies only after activation. Record them in a dependency file, and recreate the environment instead of copying its directory between machines. Do not commit .venv; add it to .gitignore.
When troubleshooting, check both the active interpreter and pip:Copy
python -c "import sys; print(sys.executable)"
python -m pip listFor small scripts, requirements.txt can be sufficient. For packages and applications, a modern pyproject.toml gives clearer metadata and build configuration. Pin or constrain dependencies according to your risk, update them deliberately, and test after upgrades.
A virtual environment is isolation, not a security boundary. Do not run untrusted code with sensitive credentials just because it is inside .venv.