# Understanding the Conda/Anaconda Ecosystem Conda is not Anaconda. [Conda](https://pydevtools.com/handbook/reference/conda.md) is a package manager; [Anaconda](https://pydevtools.com/handbook/reference/anaconda.md) 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](https://pydevtools.com/handbook/explanation/what-is-pypi.md), [pip](https://pydevtools.com/handbook/reference/pip.md), and [virtual environments](https://pydevtools.com/handbook/explanation/what-is-a-virtual-environment.md). 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](https://pydevtools.com/handbook/reference/wheel.md) 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?](https://pydevtools.com/handbook/explanation/why-should-i-choose-conda.md) 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](https://mamba.readthedocs.io/) 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](https://mamba.readthedocs.io/en/latest/user_guide/micromamba.html) 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](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md) 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](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md) apply. ### Miniforge Ships conda, mamba, and Python with [conda-forge](https://pydevtools.com/handbook/reference/conda-forge.md) 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](https://conda-forge.org/news/2024/07/29/sunsetting-mambaforge/) 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](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md) 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](https://pydevtools.com/handbook/reference/conda-forge.md) is the default channel for Miniforge and [pixi](https://pydevtools.com/handbook/reference/pixi.md). ## 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](https://pydevtools.com/handbook/reference/pixi.md), rattler) each implemented these conventions independently, occasionally diverging in edge cases. In March 2026, the conda steering council approved 10 [Conda Enhancement Proposals](https://github.com/conda/ceps) (CEPs 29-38) that formalize these conventions into specifications. The CEP process is modeled after Python's [PEP](https://pydevtools.com/handbook/explanation/pep.md) 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.bz2` and `.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](https://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. ## Bridging conda and PyPI A conda environment is logically separate from the [PyPI](https://pydevtools.com/handbook/explanation/what-is-pypi.md) ecosystem, but most projects need packages from both. The [conda-pypi](https://pydevtools.com/handbook/reference/conda-pypi.md) plugin (alpha as of 0.9.0) is the official direction for closing that gap: it installs PyPI packages as `.conda` artifacts the solver can track, replacing the long-standing convention of running `pip install` last and hoping conda never touches the environment again. For projects that need conda-forge and PyPI as equal first-class citizens in a single lockfile rather than retrofitted onto conda, [pixi](https://pydevtools.com/handbook/reference/pixi.md) is the alternative to evaluate. ## Learn more - [Why should I choose conda?](https://pydevtools.com/handbook/explanation/why-should-i-choose-conda.md) - [Is conda actually free?](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md) - [uv vs pixi vs conda for scientific Python](https://pydevtools.com/handbook/explanation/uv-vs-pixi-vs-conda-for-scientific-python.md) - [conda reference](https://pydevtools.com/handbook/reference/conda.md) - [conda-forge reference](https://pydevtools.com/handbook/reference/conda-forge.md) - [conda-pypi reference](https://pydevtools.com/handbook/reference/conda-pypi.md) - [Conda Enhancement Proposals (CEPs)](https://github.com/conda/ceps) - [Miniforge](https://github.com/conda-forge/miniforge)