Python virtual environment in 2026: venv vs uv vs conda

By Ryan Calloway. Updated May 2026.

Three tools cover the Python virtual environment problem in 2026, and they solve different problems. venv ships with Python and is the right default. uv from Astral is the fast Rust-based replacement that has gone from “interesting” in 2024 to the most-admired developer tool of 2025. conda still wins on one specific case — non-Python binary dependencies — and loses everywhere else. This guide gives you the three commands you actually need, the case for switching, and the five mistakes that cost a fresh Python install an afternoon.

Quick answer: python3.13 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt for any new project. Switch to uv when install time becomes the bottleneck (it usually does, by week two). Reach for conda only when a package needs CUDA, MKL, GDAL, or some other non-pip-installable binary backend.

What you’ll learn

The 15-second venv setup that works on every Python 3.13 install
When and how to switch to uv — the install command, the project workflow, the lockfile
The narrow case where conda is still the right answer
The difference between requirements.txt, pyproject.toml, and a lockfile
The five venv mistakes that show up weekly on r/learnpython

Prerequisites

Python 3.13 installed (3.12 also fine; older 3.x will work but you should upgrade)
A terminal — bash, zsh, fish, PowerShell, or cmd all work; activation scripts ship for each
Optional: curl for installing uv, or Homebrew on macOS

The 15-second setup with `venv`

If you only want one answer, this is it.

python3.13 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install --upgrade pip
pip install -r requirements.txt    # or: pip install requests httpx ...

Three commands plus an install. python -m venv .venv is built into every Python 3.3+ install, which covers every Python you will touch in 2026. The official venv docs are the reference; PEP 405 is the original spec.

Add .venv/ to your .gitignore. Commit requirements.txt or pyproject.toml, never the venv folder itself.

Since 2023, PEP 668 made bare pip install on a system Python an error on Debian, Ubuntu, and Homebrew installations. The error message reads “externally-managed-environment”. Read it as “create a venv”. The PEP is the formal answer to “why bother with venv at all”.

The three-tool comparison

Tool	Ships with Python	Speed	Best for
`venv` + `pip`	Yes (3.3+)	~2s setup, install 10–30s	Default. Pick this unless you have a reason not to.
`uv` 0.4+	No (one-line install)	~0.3s setup; install 10–100x faster than pip per Astral’s benchmarks	Monorepos, CI on every commit, anything where install time is the bottleneck.
`conda` 24.x / `mamba` 1.5+	No (Miniconda/Anaconda)	5–30s setup, slower solver	Data science with non-Python binary deps (CUDA, MKL, GDAL).

Pick venv unless you have a reason to pick something else. It ships with Python, has no edge cases, and is the tool every tutorial assumes.

Pick uv if you are on a project where pip install takes more than 30 seconds and you run CI on every commit. Switch to it when the time saved on installs starts dwarfing the time spent learning a new CLI.

Pick conda only when a package you need is not pure Python and not on PyPI as a wheel: CUDA-enabled builds of certain ML frameworks, GDAL, MKL-backed NumPy. For a web app or a data script with pure-Python deps, conda is extra weight and the dependency solver is slower than venv plus pip.

Activate, deactivate, delete

source .venv/bin/activate is a shell script that does three things: puts .venv/bin first on your $PATH, sets $VIRTUAL_ENV to the venv root, and prefixes your prompt with (.venv). There is no daemon, no global state, just a folder.

# Sanity check after activation
which python                 # should point inside .venv/bin
python -c "import sys; print(sys.prefix)"

# Done with the venv for now
deactivate

# Done with the project entirely
rm -rf .venv

If you need a fresh environment, delete and re-create. Do not try to clean a venv. It takes one second to rebuild and avoids subtle caching bugs.

Switching to `uv`

Install in one line:

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Or via pip / pipx / Homebrew
brew install uv

uv is one binary that replaces pip, pip-tools, pipx, virtualenv, pyenv, and poetry. Two workflows worth knowing.

The drop-in pip replacement

uv venv                                # creates .venv with current Python
source .venv/bin/activate
uv pip install -r requirements.txt    # 10-100x faster than pip
uv pip compile requirements.in --output-file requirements.txt   # lockfile
uv pip sync requirements.txt          # installs the locked set

You can switch your team to uv pip commands and the rest of the workflow does not change. Existing requirements.txt files, pyproject.toml files, and venv folders all keep working.

The full project workflow

uv init my-app                        # creates pyproject.toml + .python-version
cd my-app
uv add httpx beautifulsoup4 lxml      # adds and installs in one step
uv add --dev pytest ruff              # dev-only deps
uv lock                               # writes / updates uv.lock
uv sync                               # makes .venv match the lockfile
uv run python my_app/main.py          # runs in the project venv, no activate

The uv.lock file is universal across platforms and Python versions, which solves the “works on my Mac” problem most older lockfile tools could not. uv run means you do not have to remember to activate; uvx ruff check runs a tool in a one-shot environment.

Why people switched

uv reached ~30% of new Python repos created in 2025–2026 and topped Stack Overflow’s 2025 Developer Survey for “most admired” tag at 74.2%. The combination of speed and “one tool replaces five” is why teams move; the dependency on uv.lock being maintained by Astral is the one reason a few hold off. The project is open source under the MIT and Apache-2.0 licenses, but the maintainership story is something to know going in.

When `conda` is actually the right answer

Three cases:

You need MKL-backed NumPy/SciPy for a numeric workload where the difference matters.
You need GDAL, GEOS, or PROJ for geospatial work and getting the wheels to play nicely on your platform is more painful than installing Miniconda.
You need a specific CUDA-enabled build of a deep-learning library and the upstream maintainer ships the conda channel as the canonical install path.

Outside those cases, the conda dependency solver is meaningfully slower than uv or even pip, and the channel-priority configuration adds a class of bug pure-pip workflows do not have. mamba is the C++ reimplementation of the conda solver; if you are on conda for the binary deps, mamba is the upgrade that gets you back to acceptable install speeds. The conda docs are the canonical reference.

`requirements.txt` vs `pyproject.toml` vs lockfile

Three files, three jobs. Most projects need two of the three.

# requirements.txt - flat, pinned, used by pip and uv
httpx==0.28.1
beautifulsoup4==4.12.3
lxml==5.3.0

# pyproject.toml - project metadata + abstract deps (PEP 621)
[project]
name = "my-app"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "httpx>=0.28",
    "beautifulsoup4>=4.12",
    "lxml>=5.3",
]

[project.optional-dependencies]
dev = ["pytest>=8", "ruff>=0.6"]

# uv.lock or requirements.txt as a lockfile - exact, with hashes
# uv lock writes uv.lock automatically
# pip-tools / uv pip compile writes requirements.txt with --generate-hashes

For anything you publish to PyPI, use pyproject.toml. For a deploy target that expects requirements.txt, the older format is fine and is what most CI templates assume. For reproducibility, generate a lockfile (uv lock, uv pip compile --generate-hashes, or pip-compile) and commit it. The PEP 508 specifier language is what all three formats use under the hood.

Common mistakes

Running pip install before activating. The package goes to the system Python (or fails outright on PEP 668 systems) and the venv stays empty. Sanity check: which python right after activation should point inside .venv/bin.
Committing .venv/ to git. Hundreds of MB of platform-specific binaries, useless to your teammates. Add .venv/ to .gitignore on project number one.
Reusing one venv across two projects. Defeats the point. Project B’s requests upgrade silently breaks project A. One venv per project, no exceptions.
No requirements file at all. The venv turns into undocumented tribal knowledge on machine number one. pip freeze > requirements.txt is the minimum; hand-writing direct dependencies in pyproject.toml is the maintainable version.
Letting the IDE pick the interpreter. VS Code and PyCharm guess wrong often enough that the symptom shows up weekly on r/learnpython. Use the command palette → “Python: Select Interpreter” and pin .venv/bin/python. Also pin it in .vscode/settings.json at the workspace level so teammates do not have to repeat the dance. If you still see ModuleNotFoundError after that, the 5-minute Python fix guide covers the remaining causes.

FAQ

What is the difference between `venv` and `virtualenv`?

virtualenv is the original third-party tool from 2007. venv is the stdlib version that shipped in Python 3.3 in 2012. For new projects use venv — built in, maintained by the Python core team, covers what almost every developer needs. virtualenv still exists for edge cases like older Python versions and a few features that did not make it into the stdlib port.

Should I use `venv` or `conda`?

venv for web apps, scripts, libraries, and anything pure Python. conda only when a package needs non-Python binary dependencies (CUDA, MKL, GDAL). If you are asking the question, the answer is almost certainly venv.

Is `uv` going to replace `pip`?

For a growing share of teams, already has. The reasons to stay on pip are mostly organizational: locked-down corporate environments, CI tooling that hard-codes pip, or a team that does not want a new dependency. For a fresh project with a free choice, uv is the answer most senior Python developers I know give in 2026.

Do I need a virtual environment inside Docker?

Technically no — the container is already an isolated environment. In practice, many teams still create one inside the image for parity with local dev, faster rebuilds when only the lockfile changes, and the ability to use the same image as a dev container. Pick a convention per team and stick with it.

My activated venv uses the wrong Python version. How do I fix it?

You created the venv with the wrong interpreter. Delete the folder and re-create it with the version you want: python3.13 -m venv .venv. Use uv python install 3.13 or pyenv to keep multiple Python versions on one machine.

Can I rename a virtual environment folder?

No. The activation scripts hard-code the absolute path. Delete the folder and create a new one with the name you want. Two seconds.

What about Poetry?

Poetry was the most-recommended project manager from 2019 to 2023 and still has a meaningful install base. uv covers the same use cases (lockfile, project management, dev/prod groups) at higher speed and with a smaller surface area; new projects in 2026 mostly skip Poetry and start with uv. Migrating an existing Poetry project is straightforward — uv reads pyproject.toml and the [tool.poetry] section is intentionally close to PEP 621 metadata.

Sources and further reading

Python venv documentation — stdlib reference
PEP 405 — Python Virtual Environments — the original spec
PEP 668 — Marking Python base environments as externally-managed
PEP 508 — Dependency specification
PEP 621 — Storing project metadata in pyproject.toml
Astral uv documentation — install, project guide, pip interface
uv benchmarks — the 10-100x speed claim, with reproducible scripts
conda documentation — channel configuration, environment management
mamba — fast C++ reimplementation of the conda solver
JetBrains Python Developer Survey 2024 — adoption data on package managers and Python versions

If your venv is set up and you are still hitting ModuleNotFoundError, see the 5-minute Python fix. For the next layer up — what to put inside the project — the BeautifulSoup tutorial and the dataclasses vs Pydantic guide are the two requests/structured-data follow-ons.