Pixi: Building a Package Manager in Rust at RustNL Meetup

I attended the RustNL meetup in Amsterdam where Tim de Jager and Bas Zalmstra from prefix.dev presented their journey building Pixi — a modern package manager written entirely in Rust. The talk was titled “Introducing Pixi — A Journey of Making a Package Manager in Rust” and delivered some fascinating insights into building developer tools at scale.

What Is Pixi?

Pixi is an open-source package manager (github.com/prefix-dev/pixi — 9,000+ stars) built on the conda/conda-forge ecosystem. It supports:

• Global and Local environments via pixi.toml and pixi.lock
• Binary AND source dependencies — not just one or the other
• Multi-language projects — perfect for Robotics, Data Science, and mixed stacks
• First-class Windows support — unlike most package managers that treat Windows as an afterthought

The Philosophy

The team built Pixi around six core principles:

1. Fast — parallel downloads, reflinks, lazy solving
2. User Friendly — simple CLI, intuitive configuration
3. Isolated Environments — no global pollution
4. Single Tool — replaces conda, mamba, pip, virtualenv
5. Fun — both to use and to build
6. First-class Windows — not a second-class citizen

Who Uses Pixi?

Major projects have adopted Pixi for their development workflows:

• CPython — the reference Python implementation
• FreeCAD — open-source parametric 3D modeler
• mamba — the fast conda package manager itself
• modflow — USGS groundwater modeling
• NVIDIA/cuda-python — CUDA Python bindings

The Architecture: Four Rust Crates

The closing slide revealed the full ecosystem of projects:

1. Pixi 🐱 — the user-facing CLI and environment manager
2. Rattler 🤖 — the core library for conda package management
3. Resolvo 🧩 — a custom SAT solver for dependency resolution
4. Rattler-build 🔨 — build system for conda packages

Each project has its own mascot character and is published independently on crates.io.

Why So Fast?

This was one of the most technically interesting slides — the specific engineering decisions that make Pixi blazingly fast:

• Rattler: Parallel download, extract, and link — bounded only by IO throughput
• Rattler: Reflinks first, then hardlinks, then copy. Fresh environments cost almost nothing
• Rattler/Sparse: Crate fetches over HTTP range requests. Often skips the full archive entirely
• Rattler: Shared jlap metadata with conditional GET. Warm start is nearly free
• Resolvo: Lazy CDCL solving. Only fetches metadata for packages it actually considers

The key insight: every layer of the stack is optimized independently. The solver never fetches unnecessary metadata. The installer never copies when it can link. The downloader never transfers when it can reuse.

What They Did Right

Bas reflected on the decisions that paid off:

• Directly made Rattler into a library — not an application with library extraction later
• Started dogfooding Rattler with Pixi.dev — eating their own cooking early
• Invested into making their own solver (Resolvo) — rather than wrapping an existing SAT solver
• Had a project style which worked for them — team culture matters

What Could Have Been Done Better

The team was refreshingly honest about their mistakes:

• Did not split pixi into crates directly — monolithic at first, harder to decompose later
• Did not invest enough into faster CI:
  • Offline tests
  • Mock Registries (conda and PyPI)
• Started on the build feature late in the process — should have been earlier
• Still find it really hard to juggle features vs. issues — the eternal open-source dilemma

Tim de Jager’s Background

Tim previously worked at:

• Abbey Games — C++ game development
• Smart Robotics — C++ and Python robotics

This cross-domain experience shaped Pixi’s focus on multi-language projects. When you’ve worked in robotics where Python meets C++ meets ROS, you understand the pain of managing dependencies across language boundaries.

Why Pixi Is Fun to Build

Tim shared that working on a package manager is uniquely rewarding because:

• It combines algorithmic challenges (SAT solving, dependency resolution) with engineering problems (IO optimization, caching strategies)
• The community is grateful — developers love fast tools
• Active Discord community of ~250 members providing feedback
• His takeaway: “There is more than cargo. Working on package management is fun.”

Key Takeaways for Rust Developers

1. Library-first design pays off — make it a library from day one, not an afterthought
2. Dogfood early — use your own tool in production before others do
3. Invest in custom solutions where performance matters (Resolvo vs wrapping minisat)
4. CI speed is a feature — mock registries and offline tests save enormous time
5. HTTP range requests are underutilized — you often don’t need the full archive
6. Reflinks/hardlinks should be your first choice, copy your last resort

The Rust Package Manager Landscape

Pixi occupies an interesting niche: it’s not competing with Cargo (Rust packages) but rather with conda, pip, and mamba (Python/C++/multi-language packages). By building in Rust, they get:

• Memory safety without GC pauses during resolution
• Fearless concurrency for parallel downloads
• Zero-cost abstractions for the solver
• Cross-compilation support for all platforms

Related Posts

If you’re interested in Rust language development, check out my coverage of the Inko programming language talk from the same meetup — a language that compiles through Rust’s LLVM backend with Erlang-style concurrency.

For more on developer tooling and package management in the cloud-native space, see:

• Kustomize vs Helm — package management for Kubernetes
• ArgoCD vs Flux — GitOps delivery tools
• The Developer Burden — why tool consolidation matters

Pixi is open source at github.com/prefix-dev/pixi. The RustNL meetup was hosted at the JetBrains office in Amsterdam.