Pixi Can Now Build Packages From Source

Pixi shipped pixi-build, a preview feature that lets pixi build packages from source instead of only consuming prebuilt conda packages. The feature borrows its architecture from Python’s PEP 517 build system, but targets conda packages instead of wheels.

How it works

Python developers already know the build backend model: a frontend (pip, uv, python -m build) creates an isolated environment and calls standardized hooks on a backend (hatchling, setuptools, maturin) that produces artifacts. Pixi Build applies the same separation. Language-specific backends accept configuration and source code and produce conda packages:

• pixi-build-python handles Python projects. It reads pyproject.toml, installs the declared build backend (hatchling, setuptools, etc.) into host dependencies, and calls uv internally to install the result.
• pixi-build-rust handles Rust projects. It reads Cargo.toml and produces a conda package containing the compiled binary.

A pixi.toml manifest declares the backend and separates build-time dependencies from runtime dependencies:

[workspace]
preview = ["pixi-build"]

[package.build.backend]
name = "pixi-build-python"

[host-dependencies]
hatchling = "*"

[run-dependencies]
python = ">=3.12"
rich = ">=13"

Build dependencies (the Rust compiler, hatchling) never appear in the runtime environment. Pixi rebuilds packages in dependency order with caching, so only changed packages rebuild.

Why this matters for mixed-language projects

The announcement demonstrates a Python CLI tool that depends on a Rust binary, both managed in one pixi workspace. The Python package declares a path dependency on the Rust package; pixi builds the Rust binary first, makes it available on PATH, and then builds the Python package. No manual build scripts, no hardcoded binary paths.

This is where pixi-build goes beyond what PEP 517 covers. Python build backends produce wheels for PyPI. Pixi backends produce conda packages, which can contain compiled binaries, shared libraries, and non-Python artifacts that conda-forge consumers install without needing a compiler. A future pixi publish command will push these packages to conda channels.

Early adopters

SciPy, Xarray, Dask, and CPython have adopted pixi-build in preview. For projects that already use pixi for environment management, building from source inside the same workflow removes the gap between development and packaging.

Preview status

Pixi-build requires an explicit opt-in (preview = ["pixi-build"] in workspace configuration), and the API may change before stabilization. The pixi-build documentation covers the full configuration reference and additional patterns for git dependencies and inline manifests.

Learn more

• Pixi reference page
• When should I choose pixi over uv?
• What is a build backend?
• uv vs pixi vs conda for scientific Python