What is a Python virtual environment?

A virtual environment is an isolated Python runtime that gives each project its own set of dependencies and Python version. It prevents package conflicts between projects and avoids modifying the system Python installation.

Do I need a virtual environment in Python?

Yes. Without a virtual environment, all projects share the same packages, which leads to version conflicts when different projects need different versions of the same library. Virtual environments isolate each project so dependencies cannot interfere with each other.

How do I create a Python virtual environment?

Run `python -m venv .venv` to create one with Python's built-in venv module, then activate it with `source .venv/bin/activate` on macOS or Linux, or `.venv\Scripts\Activate.ps1` on Windows. Modern tools like uv create and manage environments automatically when you run `uv sync` or `uv run`, removing the activation step entirely.

What is the difference between venv and virtualenv?

venv ships with the Python standard library since Python 3.3 and creates environments using whatever interpreter you invoke it from. virtualenv is a third-party package that predates venv, supports older Python versions, and creates environments faster by copying a cached set of files instead of bootstrapping pip from scratch. For most modern projects, venv is sufficient and requires no extra installation.

Where should I put my virtual environment?

Place the virtual environment inside the project directory, conventionally as `.venv/`. This is the layout uv, Poetry, and PDM all use by default. Add `.venv/` to `.gitignore` because environments are not portable across machines or operating systems and should be rebuilt from a lockfile or `requirements.txt`.

What is a Virtual Environment?

by Tim Hopper · Markdown

Virtual Environments

A virtual environment is an isolated Python runtime that keeps a project’s packages separate from every other project on the machine. Each environment has its own site-packages directory, so package installations never spill across project boundaries or touch the system Python.

Installing packages into a shared Python creates three problems that compound as the number of projects grows:

Version conflicts. Different projects often require different versions of the same library. Without isolation, the last install wins and earlier projects silently break.
Dependency pollution. Every project sharing one interpreter makes it impossible to track which packages belong to which project, or to reproduce the environment on another machine.
System integrity risk. On macOS and Linux, the system Python runs internal OS tools. Overwriting a package it depends on can break those tools without warning.

How activation works

Creating a virtual environment does not change anything by itself. Activating it rewrites the shell’s PATH so that the environment’s python and pip take precedence over the system installation. The command depends on the platform and shell:

source .venv/bin/activate

After activation, the shell prompt usually changes to show the environment name in parentheses, and running pip or python invokes the environment’s copies. Running deactivate restores the original shell.

What isolation looks like in practice

A short console session makes the abstract idea of isolation concrete. On macOS or Linux:

$ which python
/usr/bin/python

$ python -m venv .venv
$ source .venv/bin/activate

(.venv) $ which python
/path/to/project/.venv/bin/python

(.venv) $ pip install cowsay
(.venv) $ python -c "import cowsay; print(cowsay.__file__)"
/path/to/project/.venv/lib/python3.14/site-packages/cowsay/__init__.py

(.venv) $ deactivate
$ python -c "import cowsay"
ModuleNotFoundError: No module named 'cowsay'

Inside the environment, cowsay imports from a file inside .venv/. Outside, the import fails entirely. Nothing was written to the system Python, and a second project can maintain its own independent set of packages without touching this one.

Let uv manage environments automatically

uv creates and activates virtual environments implicitly, removing the manual create-and-activate cycle. The traditional workflow takes four steps:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python main.py

uv run main.py handles all four. uv creates .venv if it doesn’t exist, installs dependencies from pyproject.toml, and runs the script without an explicit activation step.

Learn More

How to create and use a Python virtual environment with venv walks through the create / activate / install / deactivate lifecycle step by step.
Why should I use a virtual environment?
How to require a virtualenv when installing packages with pip
How to customize uv’s virtual environment location
venv reference
virtualenv reference

Last updated on June 10, 2026

What is a version specifier?What Is an Editable Install?

Please submit corrections and feedback...