# Conda Package


A conda package is a compressed archive containing pre-built binaries, library code, metadata, and dependency information for installation through [conda](https://pydevtools.com/handbook/reference/conda.md) channels. It serves the same role in the conda ecosystem that a [wheel](https://pydevtools.com/handbook/reference/wheel.md) serves on [PyPI](https://pydevtools.com/handbook/explanation/what-is-pypi.md), with one critical difference: conda packages can bundle software from any language (Python, R, C++, Fortran, Julia), not just Python.

## Package Formats

The conda ecosystem recognizes two archive formats, referred to as v1 and v2.

### `.tar.bz2` (v1)

The original format. A bzip2-compressed tar archive containing package contents and metadata together. Still supported by all conda tools, but slower to extract and larger on disk than the v2 format.

### `.conda` (v2)

Introduced in conda 4.7, the `.conda` format is an uncompressed ZIP container holding two inner Zstandard-compressed tar archives:

- `info-*.tar.zst` contains package metadata (dependencies, version, license, index data)
- `pkg-*.tar.zst` contains the installable files (libraries, modules, executables)

Separating metadata from content allows [conda](https://pydevtools.com/handbook/reference/conda.md), [pixi](https://pydevtools.com/handbook/reference/pixi.md), and other tools to read dependency information without extracting the full package. Zstandard decompression is faster than bzip2, and the resulting archives are smaller. conda-build produces `.conda` packages by default.

Both [conda-forge](https://pydevtools.com/handbook/reference/conda-forge.md) and the Anaconda repository publish packages in both formats, though `.conda` is preferred where available.

## Key Features

- Cross-language bundling. A single package can ship Python modules alongside compiled C/C++ libraries, R packages, or system-level dependencies like CUDA toolkits.
- Platform-specific binaries. Each package targets a specific OS and architecture (e.g., `linux-64`, `osx-arm64`, `win-64`). No compilation happens at install time.
- Non-Python dependency tracking. The dependency metadata includes system libraries and tools that Python's packaging standards cannot express.
- Channel distribution. Packages are hosted on channels such as [conda-forge](https://pydevtools.com/handbook/reference/conda-forge.md) or the [Anaconda](https://pydevtools.com/handbook/reference/anaconda.md) repository, each with its own build and licensing policies.

## Conda Packages vs. Wheels

| | Conda package | [Wheel](https://pydevtools.com/handbook/reference/wheel.md) |
|---|---|---|
| Scope | Any language | Python only |
| Non-Python deps | Tracked and resolved | Not tracked |
| Repository | Conda channels | [PyPI](https://pydevtools.com/handbook/explanation/what-is-pypi.md) |
| Build tool | conda-build or rattler-build | Any [build backend](https://pydevtools.com/handbook/explanation/what-is-a-build-backend.md) |
| Install tool | [conda](https://pydevtools.com/handbook/reference/conda.md), mamba, [pixi](https://pydevtools.com/handbook/reference/pixi.md) | [pip](https://pydevtools.com/handbook/reference/pip.md), [uv](https://pydevtools.com/handbook/reference/uv.md) |

The two formats occupy separate ecosystems. A conda package cannot be installed with [pip](https://pydevtools.com/handbook/reference/pip.md), and a wheel cannot be installed with conda. Some projects publish to both PyPI and conda-forge, giving users a choice of toolchain.

## Pros

- Handles compiled, multi-language dependency graphs that Python's packaging standards cannot represent
- Pre-built binaries eliminate the need for compilers or system-level build tools at install time
- The `.conda` v2 format extracts faster and produces smaller archives than `.tar.bz2`
- Metadata separation in the v2 format speeds up dependency resolution and channel indexing

## Cons

- Not compatible with [pip](https://pydevtools.com/handbook/reference/pip.md), [uv](https://pydevtools.com/handbook/reference/uv.md), or any PyPI-based tooling
- Building a conda package requires conda-build or rattler-build, both more involved than standard Python build backends
- Package availability depends on the channel; niche Python libraries may exist on PyPI but not on any conda channel
- Mixing conda-installed and pip-installed packages in the same environment can cause conflicts

## Learn More

### Handbook pages

- [Understanding the Conda/Anaconda ecosystem](https://pydevtools.com/handbook/explanation/understanding-the-conda-anaconda-ecosystem.md)
- [Why should I choose conda?](https://pydevtools.com/handbook/explanation/why-should-i-choose-conda.md)
- [conda reference](https://pydevtools.com/handbook/reference/conda.md)
- [conda-forge reference](https://pydevtools.com/handbook/reference/conda-forge.md)
- [Wheel reference](https://pydevtools.com/handbook/reference/wheel.md)

### Official documentation

- [Conda package specification](https://docs.conda.io/projects/conda/en/stable/user-guide/concepts/packages.html)
- [Package file format specification](https://conda.org/learn/specifications/)
- [conda-build documentation](https://docs.conda.io/projects/conda-build/en/stable/)
- [conda-package-handling library](https://conda.github.io/conda-package-handling/)
- [conda/ceps on GitHub](https://github.com/conda/ceps)