---
title: Don't use Conda, use Pixi!
shorttitle: Don't use Conda, use Pixi!
slug: use-pixi
date: 01/16/2026
thumbnail: '/thumbnails/prefix.png'
tag: package-management
canonicalUrl: 'https://sanjaycnagi.com/blog/2026-01-16-use-pixi/'
---


The bioinformaticians amongst will be familiar with the Conda package manager - for a long time, it has been the go to package management tool in the world of open source software. It allows us to install, update, and manage software packages and their dependencies across multiple programming languages, whilst creating isolated environments so different projects can use different package versions without conflicts. Whilst incredibly useful as a tool, Conda is also notorious for being extremely slow, heavy on storage, and mixing Conda with pip (the Python package manager) can often lead to cryptic dependency conflicts which are hard to debug. 
 
**Enter Pixi 🧚 !**    
Pixi is a modern re-thinking of Conda, developed by the team at [prefix.dev](https://prefix.dev/) (some of whom developed Conda itself). At its core, Pixi uses the same underlying ecosystem of Conda packages, primarily from the conda-forge and bioconda repositories, but rethinks how environments are created, solved, and shared.

**Blazing fast 🚀**  
Pixi is built on top of rattler, a modern dependency resolver written in Rust. In practice, this makes environment resolution dramatically faster than classic Conda, which was written in Python. Rattler also uses a much more efficient solver implementation, and all of this this means that creating or updating environments feels almost instantaneous.

**Lockfiles 🔒**  
Pixi also introduces lockfiles, a now well-established concept that was first popularised in the JavaScript ecosystem, most notably with npm's package-lock.json and yarn's yarn.lock. These tools recognised early on that simply specifying version ranges (e.g. ^1.2.0) was not enough to guarantee reproducible installs, because transitive dependencies could still change underneath you. Lockfiles solved this by recording the exact dependency graph that was resolved at install time. The mottivation is to separate intent from resolution - that is, a main config file (pixi.toml) expresses what you want, while the lockfile records what you actually got.

Pixi applies this pattern to the Conda world, where reproducibility has traditionally been much harder to achieve. Classic Conda environment files specify dependency ranges but leave resolution to the solver each time, meaning two installs on different days or machines can yield subtly different environments. Pixi’s lockfile approach brings Conda in line with modern package managers by making environment resolution deterministic, shareable, and ultimately more reproducible.

**A project-centric workflow 📁**   
Pixi encourages a clean, project-based way of working. Each project lives in its own directory with a pixi.toml file describing dependencies and tasks, alongside a lockfile that captures the resolved environment. There is no global “base” environment to accidentally break, and the structure of a project is immediately clear to anyone new to it. This fits naturally with modern development practices and makes projects easier to share, version-control, and archive.

**Safer pip integration 🧪**  
Mixing Conda and pip has historically been a source of subtle and painful bugs. Pixi makes this safer by being explicit about pip dependencies and capturing them in the lockfile alongside Conda packages. You still get the flexibility of pip, but with much better guarantees that your environment will remain consistent.

---

I’ve now been using Pixi for the past 6 months or so, and it has made life as a data scientist much more convenient. If you use Conda a lot, Pixi is well worth exploring.


🔥 1 Posts filtered by tag "package-management"

Don't use Conda, use Pixi!