# Pixi Can Now Build Packages From Source


[Pixi](https://pydevtools.com/handbook/reference/pixi.md) shipped [pixi-build](https://prefix.dev/blog/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](https://pydevtools.com/handbook/explanation/what-is-pep-517.md) build system, but targets conda packages instead of wheels.

## How it works

Python developers already know the [build backend](https://pydevtools.com/handbook/explanation/what-is-a-build-backend.md) model: a frontend (pip, [uv](https://pydevtools.com/handbook/reference/uv.md), `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](https://pydevtools.com/handbook/explanation/what-is-a-build-backend.md) (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:

```toml
[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](https://pydevtools.com/handbook/reference/conda-forge.md) 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](https://pixi.sh/latest/features/build/) covers the full configuration reference and additional patterns for git dependencies and inline manifests.

## Learn more

- [Pixi reference page](https://pydevtools.com/handbook/reference/pixi.md)
- [When should I choose pixi over uv?](https://pydevtools.com/handbook/explanation/when-should-i-choose-pixi-over-uv.md)
- [What is a build backend?](https://pydevtools.com/handbook/explanation/what-is-a-build-backend.md)
- [uv vs pixi vs conda for scientific Python](https://pydevtools.com/handbook/explanation/uv-vs-pixi-vs-conda-for-scientific-python.md)