Skip to content

Conda Package

by Tim Hopper
Scientific Python Packaging

A conda package is a compressed archive containing pre-built binaries, library code, metadata, and dependency information for installation through conda channels. It serves the same role in the conda ecosystem that a wheel serves on PyPI, 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, pixi, 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 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 or the Anaconda repository, each with its own build and licensing policies.

Conda Packages vs. Wheels

Conda package Wheel
Scope Any language Python only
Non-Python deps Tracked and resolved Not tracked
Repository Conda channels PyPI
Build tool conda-build or rattler-build Any build backend
Install tool conda, mamba, pixi pip, uv

The two formats occupy separate ecosystems. A conda package cannot be installed with pip, 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, uv, 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

Official documentation

Last updated on
Condaconda-forge

Please submit corrections and feedback...