Anaconda vs {pyenv + pipenv} (and uv)

Updated June 2026 · 5 minute read
Updated for 2026. Examples assume Linux (Ubuntu 22.04+) or macOS (incl. Apple Silicon) with a bash/zsh shell; adapt paths for your OS.

Anaconda / Miniconda / Miniforge

Anaconda is a cross-platform Python and R distribution aimed at data science and machine learning — a large collection of pre-built packages (the PyData ecosystem) plus Conda, an open-source package, dependency and environment manager that works for any language (Python, R, C/C++, FORTRAN, …) and, crucially, handles non-Python binary dependencies (MKL, CUDA, GDAL, …) that pip cannot.

Most people get Conda through one of the minimal installers rather than the full Anaconda distribution:

  • Miniconda — minimal installer for Conda from Anaconda Inc., using the defaults channels:
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh
  • Miniforge — community installer that defaults to the free conda-forge channel and ships mamba. Recommended if you want to avoid Anaconda’s commercial terms for the defaults channels (relevant for organisations) and prefer conda-forge:
wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh
bash Miniforge3-$(uname)-$(uname -m).sh

Either way, create and use environments the same way — and prefer mamba (a fast, drop-in C++ reimplementation of the Conda solver; bundled with Miniforge) for much quicker installs:

mamba create -n ds python=3.13 numpy scikit-learn jupyterlab
mamba activate ds

The full Anaconda distribution uses several GB of disk; a Miniconda/Miniforge base is a few hundred MB and you add only what you need. If you live in the PyData ecosystem or depend on heavy binary/GPU packages, a conda-based setup is hard to beat — Conda resolves those native dependencies for you.

pyenv + pipenv (the classic setup)

With some command-line comfort you can assemble a comparable, lighter setup from focused tools — and learn a lot along the way. We will:

  1. install pyenv — manage multiple Python versions side by side;
  2. install some Python versions and create virtual environments;
  3. install pipenv — per-project dependency management with a Pipfile / Pipfile.lock;
  4. install JupyterLab.

Install the build dependencies (Ubuntu/Debian; see the pyenv wiki for other distros and macOS), then pyenv itself:

sudo apt update
sudo apt -y install build-essential curl git \
  libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
  libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev
# install pyenv (adds ~/.pyenv)
curl -fsSL https://pyenv.run | bash

Add pyenv to your shell (use ~/.zshrc on zsh), then restart the shell:

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc

Install Python versions and set a default:

pyenv install 3.13
pyenv install 3.12
pyenv global 3.13
python --version

Then use pipenv per project — it creates the virtualenv and keeps Pipfile / Pipfile.lock in sync as you add or remove packages, for reproducible installs:

cd ~/workspace && mkdir myproject && cd myproject
pipenv --python 3.13          # creates the project virtualenv
pipenv install numpy scikit-learn jupyterlab
pipenv run jupyter lab        # or: pipenv shell

This gives you, in a few hundred MB, multiple Python versions and a per-project, lock-file-backed workflow. You install only what each project needs — more setup than Anaconda’s batteries-included approach, but more transparent and pip-native.

uv — the modern one-tool answer

uv (by Astral, written in Rust) is the biggest change since this post was written. A single, very fast tool that replaces pyenv, virtualenv, pip and pipenv: it installs Python versions, creates environments, resolves dependencies and writes a uv.lock, all around the standard pyproject.toml.

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

# uv manages Python versions too (no pyenv needed)
uv python install 3.13

# start a project: creates pyproject.toml + .venv, writes uv.lock
uv init myproject && cd myproject
uv add numpy scikit-learn jupyterlab
uv run jupyter lab            # runs inside the managed environment

Need a quick, pip-compatible throwaway environment instead of a project?

uv venv --python 3.13
uv pip install numpy scikit-learn

uv is typically an order of magnitude faster than the pip/pipenv path and needs no shell-init gymnastics. For most general-purpose Python work in 2026, it is the simplest and quickest option.

So which should you use?

  • Heavy data science / native or GPU dependencies (NumPy+MKL, CUDA, geospatial, R interop): a conda setup — Miniforge + mamba — still wins, because Conda resolves the non-Python binaries pip cannot.
  • General Python development: reach for uv. It subsumes pyenv + pipenv + virtualenv in one fast, lock-file-based tool.
  • pyenv + pipenv: still perfectly fine if you are already invested, but for new setups uv covers the same ground with far less ceremony.

Unless you are squarely in the PyData ecosystem, Anaconda is no longer the obvious default — and even there, Miniforge + mamba is the leaner, license-clean path.

Enjoy coding!

References for further reading:

  1. uv documentation
  2. pyenv command reference
  3. pipenv documentation
  4. mamba documentation
  5. Miniforge
Above opinions and any mistakes are my own. I am not affiliated in any way with companies, or organizations mentioned above. The code samples provided are licensed under the Apache 2.0 License and rest content of this page is licensed under the Creative Commons Attribution 3.0 License, except if noted otherwise.