Python Virtual Environments Explained: venv vs uv vs conda

What a Python virtual environment actually is, why every project needs one, and how venv, uv, and conda differ in creating them

Every “install this and it broke my other project” problem in Python traces back to the same root cause: packages installed globally instead of isolated per project. Virtual environments fix that, and every packaging tool worth using is built around creating one.

What a virtual environment actually is

A virtual environment is a self-contained directory with its own Python interpreter (or a symlink to one) and its own site-packages folder for installed libraries, isolated from your system Python and from every other project’s environment. Activate it, and pip install requests puts requests only inside that folder — a different project with a different environment can have a completely different version of requests, or none at all, without conflict.

venv: built in, manual

venv ships with Python itself — no installation needed. python -m venv .venv creates the environment, source .venv/bin/activate activates it, and you’re on your own for everything else: installing packages with plain pip, tracking what’s installed via a hand-maintained requirements.txt. It works, but it’s the manual-transmission version of environment management.

uv: fast, integrated into a full workflow

uv creates and manages virtual environments as part of its broader project-management workflow — uv venv creates one directly, or more commonly you never think about it explicitly at all, since uv sync creates the environment and installs locked dependencies into it in one step. The underlying mechanism is similar to venv, but uv wraps it in tooling that also handles locking and dependency resolution, which plain venv doesn’t attempt.

conda: environments plus non-Python dependencies

Conda environments go further than the other two: alongside Python packages, conda can install and manage non-Python dependencies — compiled C libraries, CUDA toolkits, specific compiler versions — inside the same isolated environment. That’s the entire reason it exists as a separate ecosystem from pip-based tools, and it’s specifically relevant for data science and ML work where a package like a GPU-accelerated library needs system-level dependencies pip can’t install on its own.

Which one to use

For a typical web app, CLI tool, or library with only Python dependencies: uv, and let it manage the virtual environment for you as part of the wider workflow — see our packaging tools guide for the fuller picture. Plain venv is worth knowing because it’s what every tutorial assumes as a baseline and requires no installation, but it’s rarely the best choice once you have an alternative available. Reach for conda specifically when your project has non-Python system dependencies conda’s package management genuinely solves — most projects don’t.