Python Pixi Package Manager — Core Concepts

Why this topic matters

The Python ecosystem has many package managers (pip, conda, poetry, pdm), each solving part of the problem. Pixi, built by the prefix.dev team in Rust, aims to be a unified project manager that handles conda and PyPI packages, creates lock files for reproducibility, runs tasks, and manages multiple environments — all from a single pixi.toml configuration file.

How it works

Getting started

# Install pixi (single binary, no dependencies)
curl -fsSL https://pixi.sh/install.sh | bash

# Create a new project
pixi init my-project
cd my-project

# Add dependencies
pixi add python=3.12 numpy pandas matplotlib

# Run Python in the managed environment
pixi run python script.py

Pixi creates two files:

• pixi.toml: Your project configuration (what you want)
• pixi.lock: Exact resolved versions (what you get)

The pixi.toml file

[project]
name = "data-analysis"
version = "0.1.0"
description = "Sales data analysis pipeline"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64", "win-64"]

[dependencies]
python = ">=3.11,<3.13"
numpy = ">=1.26"
pandas = ">=2.0"
matplotlib = ">=3.8"

[pypi-dependencies]
wandb = ">=0.16"
transformers = ">=4.38"

[tasks]
start = "python main.py"
test = "pytest tests/ -v"
lint = "ruff check src/"
format = "ruff format src/"

Key concepts

Automatic lock file

When you run pixi add or pixi install, Pixi resolves all dependencies and writes pixi.lock. This lock file captures:

• Exact package versions and builds
• Cryptographic hashes for integrity
• Platform-specific resolution (one lock file, multiple platforms)

Teammates run pixi install and get identical environments — no solving needed, no version drift.

Conda and PyPI together

Pixi natively supports both conda channels and PyPI:

[dependencies]
# From conda-forge (handles C libraries, CUDA, etc.)
python = "3.12.*"
cuda-toolkit = "12.1.*"
opencv = ">=4.9"

[pypi-dependencies]
# From PyPI (Python-only packages)
fastapi = ">=0.110"
uvicorn = ">=0.27"

Conda packages are installed first, then PyPI packages — avoiding the conflicts that arise when mixing pip and conda manually.

Task runner

Define common commands in pixi.toml:

[tasks]
serve = "uvicorn app:main --reload"
test = "pytest tests/ -v --cov"
migrate = "alembic upgrade head"
docker-build = "docker build -t myapp ."

# Task dependencies
ci = { depends-on = ["lint", "test"] }
lint = "ruff check src/"

Run them:

pixi run serve
pixi run ci      # Runs lint, then test

This replaces Makefiles or script collections for common project commands.

Multiple environments

Different workflows can have different dependencies:

[feature.test.dependencies]
pytest = ">=8.0"
pytest-cov = "*"

[feature.docs.dependencies]
sphinx = ">=7.0"
sphinx-rtd-theme = "*"

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

pixi run -e docs sphinx-build docs/ build/
pixi run test  # Uses default environment

Platform-specific dependencies

[target.linux-64.dependencies]
cuda-toolkit = "12.1.*"

[target.osx-arm64.dependencies]
mlx = ">=0.5"

[target.win-64.dependencies]
pywin32 = "*"

The lock file resolves each platform independently, so one pixi.toml serves Linux, macOS, and Windows.

Common misconception

“Pixi is just another conda wrapper.” While Pixi uses conda channels, it’s a fundamentally different tool. It introduces project-level configuration (like Cargo or npm), automatic lock files, a built-in task runner, PyPI integration, and multi-platform resolution — none of which conda provides natively.

One thing to remember

Pixi brings the best ideas from modern package managers — lock files, task running, multi-environment support — to the conda ecosystem. One pixi.toml, one pixi.lock, and any contributor can reproduce your exact environment with pixi install.