Skip to content

Pixi: Multi-Language Package and Workflow Manager

by Tim Hopper · Markdown
Scientific Python

Pixi is a cross-platform package manager and workflow tool that manages both conda-forge packages and PyPI packages from a single project manifest. It replaces conda’s global environment model with project-local environments and automatic lockfiles.

Note

Pixi targets the same package ecosystem as conda but with a different workflow model. If you don’t need conda-forge packages, uv is a simpler choice. See When should I choose pixi over uv? for a detailed comparison.

When to use pixi

Use pixi when your project depends on native libraries that conda-forge packages more reliably than PyPI: CUDA toolkits, GDAL, HDF5, OpenCV, MKL, NetCDF. Some of these have PyPI packages, but conda-forge bundles the underlying C/C++/Fortran libraries so you don’t need to install them separately. Pixi also works well for mixed-language projects (Python + R, Python + C++) and for teams that want reproducible cross-platform lockfiles covering both conda and PyPI dependencies.

For pure Python projects, uv provides a simpler workflow.

Installation 

curl -fsSL https://pixi.sh/install.sh | bash

This installs the pixi binary to ~/.pixi/bin (macOS/Linux) or %UserProfile%\.pixi\bin (Windows). See the official installation guide for other methods.

Project setup

Initialize a new project with pixi init:

pixi init my-project
cd my-project

This creates a pixi.toml manifest:

[workspace]
authors = ["Your Name <you@example.com>"]
channels = ["conda-forge"]
name = "my-project"
platforms = ["osx-arm64"]  # auto-detected from your system
version = "0.1.0"

[dependencies]

[tasks]

To use pyproject.toml instead (useful if you’re building a Python package):

pixi init --format pyproject my-project

With pyproject.toml, pixi configuration lives under [tool.pixi.*] sections (e.g. [tool.pixi.workspace], [tool.pixi.dependencies]), while standard [project] metadata remains portable to other Python tools.

Managing dependencies

Conda packages 

pixi add python numpy pandas

PyPI packages 

pixi add --pypi requests

Pixi resolves conda dependencies first, then resolves PyPI packages against what conda already installed. It uses uv internally for PyPI resolution.

Installing the environment 

pixi install

This creates a .pixi/ directory containing the project environment. The directory is local to the project and should be added to .gitignore (pixi does this automatically on pixi init).

Running commands 

# Run a command in the project environment
pixi run python main.py

# Start an interactive shell
pixi shell

Tasks

Pixi includes a built-in task runner. Tasks are defined in pixi.toml and run within the project environment.

# Add tasks
pixi task add test "pytest -s"
pixi task add lint "ruff check ."

# Run a task
pixi run test

Tasks can also be defined directly in pixi.toml with dependencies on other tasks:

[tasks]
lint = "ruff check ."
test = { cmd = "pytest -s", depends-on = ["lint"] }

Multi-environment support

Pixi can define multiple environments from composable “features.” Each feature is a named set of dependencies; environments combine one or more features. Named environments include the default feature’s dependencies unless you set no-default-feature = true.

[dependencies]
python = ">=3.12"
numpy = ">=2.0"

[feature.test.dependencies]
pytest = ">=8"

[feature.docs.dependencies]
sphinx = ">=7"

[environments]
test = ["test"]
docs = ["docs"]

Run commands in a specific environment:

pixi run --environment test pytest
pixi run --environment docs sphinx-build docs build

Cross-platform lockfiles

Pixi resolves dependencies for all target platforms in a single pixi.lock file. Add platforms with:

pixi workspace platform add linux-64 win-64

The lockfile captures the full dependency graph for every platform and environment combination. Each platform is solved separately, so exact builds may differ across OSes, but every collaborator gets a reproducible install for their platform.

Pixi 0.68.0 (May 2026) upgraded the lockfile format to version 7. The upgrade is automatic on the next pixi lock or pixi update, but older pixi builds cannot read v7 lockfiles. Coordinate the upgrade across collaborators and CI before committing a regenerated pixi.lock. Version 7 also records build and host environments (making source builds reproducible across machines), eliminates churn from comment-only manifest edits, and keeps relative paths relative for Docker and cross-machine portability.

Tool management

Like pipx or uvx, pixi can install CLI tools globally or run them in temporary environments:

# Install a tool globally
pixi global install ruff

# Run a tool without installing it
pixi exec black --check .

# List globally installed tools
pixi global list

Building packages from source (preview)

Pixi Build lets pixi build packages from source instead of only consuming prebuilt conda packages. The system uses language-specific build backends inspired by Python’s PEP 517 build backend protocol: pixi-build-python for Python projects (using hatchling and uv internally) and pixi-build-rust for Rust projects.

Enable the feature with a preview flag in pixi.toml:

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

Configure a build backend in the package manifest:

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

[host-dependencies]
hatchling = "*"

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

Build dependencies stay isolated from the runtime environment. Pixi rebuilds packages in dependency order with caching, so a monorepo with path dependencies (fibtable = { path = "." }) rebuilds only what changed.

SciPy, Xarray, Dask, and CPython have adopted pixi-build in early preview. See the pixi-build documentation for the full configuration reference.

Other useful commands 

# Search for a package on configured channels
pixi search opencv

# Show the dependency tree
pixi tree

# Show environment and system info
pixi info

# Update dependencies to latest compatible versions
pixi update

Supply chain security

Pixi 0.67.0 added exclude-newer, which delays adoption of newly released packages by a configurable period. This allows vulnerabilities to surface in the ecosystem before they reach a project’s resolved dependencies.

Set a workspace-wide cooldown in pixi.toml:

[workspace]
exclude-newer = "7d"

Per-channel or per-package overrides are supported for packages under internal control:

[workspace]
channels = [
  "conda-forge",
  { channel = "https://prefix.dev/my-channel", exclude-newer = "0d" },
]
exclude-newer = "14d"

[exclude-newer]
my-internal-package = "0d"

The value accepts a duration ("7d", "30d") or an ISO date ("2026-01-01"). The setting applies to both conda and PyPI packages.

Learn more

Last updated on
pipxpoetry