Virtual environments isolate dependencies per project; global installs cause conflicts
A virtual environment is a directory containing its own Python interpreter and its own site-packages. When activated, the venv's bin directory is prepended to PATH and its site-packages is used instead of the system one. The purpose is isolation: two projects can depend on different versions of the same library without conflict, and installing or upgrading a package for one project cannot break another or the system Python. Global installs are dangerous because system tools and other applications may rely on specific versions, and because pip install --user pollutes the user site-packages across all projects. Modern Python ships venv in the standard library, and tools like poetry, pdm, and conda manage environments and lock files on top of it. For deployment, environments are usually created in a container or a dedicated virtualenv rather than installed globally.
venv: python -m venv .venv creates an isolated environment in the current directory.
Activate with source .venv/bin/activate on Unix or .venv\Scripts\activate on Windows.
Tools: virtualenv for older versions, poetry and pdm for dependency resolution and locking, conda for data science stacks.
Lock files (poetry.lock, pdm.lock, requirements.txt with hashes) make installs reproducible.
Common mistake: installing with sudo pip install, which modifies system packages and can break the OS tooling.
Common mistake: committing the .venv directory to version control. It is large and platform-specific.
Version note: venv is in the stdlib since 3.3. Python 3.12 removed distutils, which affected some legacy build paths; setuptools and pip have been updated accordingly.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience