Understanding the Conda/Anaconda Ecosystem
Conda is not Anaconda. Conda is a package manager; Anaconda is a distribution that bundles conda with over 1,500 pre-installed packages. Confusing the two is common, and it leads to choosing the wrong installer or paying for a commercial license you don’t need.
The conda ecosystem operates as a parallel system to Python’s standard packaging tools like PyPI, pip, and virtual environments. Conda uses its own package format, repository structure, and environment management. The two ecosystems can coexist, but they work independently.
Why conda exists
In 2012, before wheels became the standard distribution format, installing scientific libraries like NumPy or SciPy required compiling C and Fortran extensions against system-level dependencies. Conda solved this by shipping pre-compiled binaries with all dependencies bundled.
That origin explains both conda’s design choices and its continued prominence in scientific computing. Unlike Python-specific tools, conda manages dependencies across multiple programming languages: Python, R, C++, and others in a single environment. See Why should I choose conda? for when this cross-language capability matters.
Package managers
Conda
The foundational package manager. It resolves dependency trees across languages, creates isolated environments, and manages Python interpreters alongside non-Python libraries. Conda’s default solver is written in Python and can be slow on large dependency graphs.
Mamba and micromamba
Mamba reimplements conda’s solver in C++ (via libmamba), making resolution and installation faster. Since conda 23.10, conda itself can use libmamba as its solver backend (conda config --set solver libmamba), narrowing the performance gap.
Micromamba is a single statically-linked binary that implements the mamba interface without requiring a base conda installation. It is useful in CI environments and containers where a minimal footprint matters.
Distributions
A distribution bundles a package manager with a Python interpreter and a default channel configuration. Choosing a distribution determines two things: which package manager you start with and which repository your packages come from by default.
Anaconda Distribution
Ships the conda package manager, a Python interpreter, and over 1,500 pre-installed scientific packages. Packages come from the Anaconda repository, which requires a paid license for organizations with more than 200 employees. Includes Anaconda Navigator, a GUI for managing environments.
Miniconda
Ships conda and Python with no pre-installed scientific packages. Uses the Anaconda repository as the default channel, so the same commercial licensing terms apply.
Miniforge
Ships conda, mamba, and Python with conda-forge as the default channel. No commercial licensing restrictions apply. Miniforge is the recommended installer for teams that want the conda ecosystem without Anaconda’s licensing terms.
Note
Mambaforge, a variant that shipped mamba instead of conda, was deprecated in mid-2024 after Miniforge added mamba by default. Existing Mambaforge users should switch to Miniforge.
Package channels
Channels are repositories of conda packages. The channel you configure determines which packages are available and under what terms.
Anaconda repository
The default channel for Anaconda Distribution and Miniconda. Anaconda Inc. curates and builds the packages. Commercial use requires a license for organizations above 200 employees.
conda-forge
A community-maintained channel with over 30,000 packages, automated builds, and transparent maintenance. Free for all use, including commercial. conda-forge is the default channel for Miniforge and pixi.
Specifications and standards
For most of its history, conda’s core behaviors (what counts as a valid package name, how version strings compare, what a conda environment directory contains) were de facto conventions rather than documented specifications. Different tools (conda, mamba, pixi, rattler) each implemented these conventions independently, occasionally diverging in edge cases.
In March 2026, the conda steering council approved 10 Conda Enhancement Proposals (CEPs 29-38) that formalize these conventions into specifications. The CEP process is modeled after Python’s PEP system. The new specifications cover:
- Package and channel identifiers (what characters are allowed in names)
- Version string format and comparison rules
- MatchSpec syntax (how dependency constraints are expressed)
- Virtual packages
- Build provenance
- Environment directory structure
- Package file formats (
.tar.bz2and.conda) - Repodata (the repository index format)
conda-lock.yml(the lockfile format)- Channeldata (channel-level metadata)
These specifications are organized at conda.org/learn/specifications. The practical effect: conda, mamba, pixi, and rattler now share a single source of truth for how packages, environments, and repositories are defined.