Python venv vs virtualenv vs pipx: when to use which in 2026
Three tools, overlapping names, genuinely different jobs. Picking the wrong one is why people end up with a global Python install full of unrelated CLI tools, or a project venv that won't build because a system package is missing.
venv — isolate dependencies for one project
Built into the standard library since Python 3.3 — no install needed, python3 -m venv
.venv just works (when it works; see the caveat below). Creates an isolated environment
with its own site-packages, so a project's dependencies don't collide with the system
Python or with another project's dependencies.
python3 -m venv .venv
source .venv/bin/activate # .venv\Scripts\activate on Windows
pip install -r requirements.txt
Use venv for: any project with its own dependencies — a web app, a script with a few
third-party libraries, anything you'd normally put in a requirements.txt.
Caveat that trips people up on newer Debian/Ubuntu (24.04+): python3 -m venv can fail
with "ensurepip is not available" because Ubuntu splits that piece into a separate
python3.X-venv package. If you have sudo, apt install python3-venv fixes it. If you
don't, python3 -m venv --without-pip .venv followed by bootstrapping pip directly into
the venv works without touching system packages at all — a distinct problem from the one
below, easy to conflate since both show up as "pip is broken."
virtualenv — the older, more portable third-party version
Predates venv, needs a separate install (pip install virtualenv), and still sees use
mainly for two things venv doesn't do as well: creating environments for Python versions
other than the one currently running (given the right interpreter is installed), and
working consistently across older Python versions where venv's behavior varied. For a
plain "isolate this project's dependencies" job on a reasonably current Python, venv
does the same thing with nothing extra to install — most new projects don't need
virtualenv specifically anymore.
pipx — install a CLI tool once, use it everywhere, without polluting anything
Different problem entirely. pipx isn't for project dependencies — it's for installing
Python-based command-line tools (black, httpie, poetry, ruff, etc.) so you can run
them from any directory, while keeping each tool in its own isolated environment behind
the scenes so their dependencies never conflict with each other or with a project's venv.
pipx install black
black --version # works from anywhere, no active venv needed
Use pipx for: command-line tools you want available globally. Don't use it for: a
project's own dependencies — those belong in that project's venv, not installed globally
via pipx.
The actual decision
| Situation | Use |
|---|---|
| A project has its own dependencies (a requirements.txt or pyproject.toml) | venv |
| You need a specific Python version's environment, or support older Python | virtualenv |
| You want a CLI tool runnable from anywhere, isolated from everything else | pipx |
In practice: venv covers the large majority of "isolate my project" needs on any current
Python install, pipx handles the separate "install a tool globally" need, and
virtualenv is worth reaching for specifically when venv's behavior or version support
falls short.
Sources: Python standard library venv documentation; virtualenv project documentation;
pipx project documentation; the python3-venv packaging split verified directly against
Ubuntu 26.04.