venv vs conda vs uv — which Python environment tool should you use?

Install everything globally and two projects eventually need different versions of the same package. One of them breaks. Then you reinstall Python, and both break.

An environmentA private folder with its own Python and its own installed packages fixes this by giving each project its own package folder. Three tools do it, and the choice is genuinely simple once you know what each is for.

Short answer: venv if you are learning, uv if you want speed, conda if you need CUDA or non-Python libraries.

The comparison

venv — the one already on your machine

Nothing to install. It ships with Python.

python -m venv .venv

Activate it:

# Windows PowerShell
.venv\Scripts\Activate.ps1

# Windows Command Prompt
.venv\Scripts\activate.bat

# macOS / Linux
source .venv/bin/activate

Your prompt now shows (.venv). Install as usual:

python -m pip install pandas scikit-learn
python -m pip freeze > requirements.txt

Someone else rebuilds it with:

python -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt

Deactivate with deactivate. Delete the environment by deleting the .venv folder — there is no hidden state anywhere else.

Use venv when: you are learning, the project is pure Python, and you want the fewest moving parts.

Weak spot: pip freeze records what you have, not what you asked for. Your file ends up listing sixty transitive dependencies, and nobody can tell which four you actually chose.

uv — the fast one

uv is a Rust reimplementation of pip and venv. It is not marginally faster; it is often twenty to a hundred times faster, which changes how you work.

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

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

Start a project:

uv init my-project
cd my-project
uv add pandas scikit-learn
uv run python train.py

Three things happened quietly: uv created the environment, wrote pyproject.toml with your direct dependencies, and produced uv.lock pinning every exact version. uv run activates the environment for that command, so you never have to remember to activate.

It also installs Python itself:

uv python install 3.12
uv venv --python 3.12

And it replaces pip commands directly, which is handy on an existing project:

uv pip install -r requirements.txt

Use uv when: you want reproducible builds, fast CI, or you are tired of waiting for pip.

Weak spot: it is young. Most things work; occasionally a package with unusual build steps needs a fallback to pip.

conda — the one for scientific stacks

conda installs more than Python packages. It installs compiled libraries — CUDA toolkits, GDAL, MKL, FFmpeg — which pip cannot manage.

conda create -n ml python=3.11
conda activate ml
conda install -c conda-forge pandas scikit-learn

Its real value shows up here:

conda install -c pytorch -c nvidia pytorch pytorch-cuda=12.1

That one line installs PyTorch and the matching CUDA runtime, correctly paired. Doing this by hand with pip is a well-known way to lose an afternoon.

Share the environment:

conda env export --from-history > environment.yml
conda env create -f environment.yml

Use --from-history. Without it, the file records every transitive package pinned to your exact platform, and it will not rebuild on a different operating system.

Use conda when: you need GPU deep learning, geospatial libraries, or bioinformatics tools.

Weak spot: slow solving, large installs, and mixing conda install with pip install in one environment can produce genuinely confusing breakage. If you must mix, install everything from conda first and use pip only for what is left.

Choosing

Rules that apply to all three

One environment per project. Not per language, not per year. Per project.

Never commit the environment folder. Add to .gitignore:

.venv/
venv/
env/

Commit the recipe — requirements.txt, pyproject.toml plus uv.lock, or environment.yml.

Always use python -m pip, never bare pip. It guarantees the package lands in the interpreter you are running. This one habit prevents No module named 'cv2' and half the "but I installed it!" confusion on the internet.

Point your editor at the environment. In VS Code: Ctrl+Shift+P → Python: Select Interpreter → pick the one inside your project folder.

Migrating between them

requirements.txt → uv

uv init
uv add -r requirements.txt

conda → venv (only if you have no compiled dependencies)

conda list --export > conda-packages.txt
# then hand-write requirements.txt with the packages you actually use

venv → conda

conda create -n myenv python=3.11
conda activate myenv
python -m pip install -r requirements.txt

FAQ

Should I use venv, conda or uv?

Use venv while learning, uv for speed and reproducible locks in normal Python projects, and conda when you need compiled non-Python libraries such as CUDA or GDAL.

Is uv a replacement for pip and venv?

Largely yes. uv venv replaces venv, uv pip install replaces pip, and uv add manages dependencies with a lockfile. Keep pip available for the occasional package with unusual build requirements.

Why is conda so slow?

conda solves a dependency graph that includes compiled system libraries, not just Python packages, which is a much larger problem. Using the conda-forge channel and the newer solver helps considerably.

Can I mix conda and pip in one environment?

It works but breaks in confusing ways when both manage the same package. Install everything available from conda first, then use pip only for what remains.

Should I commit the .venv folder to git?

No. Add it to .gitignore and commit the recipe instead — requirements.txt, or pyproject.toml with uv.lock.

Next reading on Sythra Articles

• 'pip' is not recognized — fix it on Windows
• ModuleNotFoundError: No module named 'cv2'
• Jupyter vs VS Code vs Colab for learning ML