Conda vs Pixi | Daniel's Bast Practices Blog

Table of Contents

conda vs pixi sounds like a normal tool comparison.

Old vs new. Python vs Rust. Slow vs fast. Legacy vs modern. Enterprise vs startup. Base environment vs single binary. environment.yml vs pixi.toml.

That framing is useful for about five minutes. Then it gets in the way.

The interesting question is not which tool wins. It is what this comparison reveals about the conda ecosystem: how a package manager becomes infrastructure, why new implementations are healthy, why standards matter more than clients, and why fast tools are also about sensing what users need.

Disclaimer
I am not writing this as a neutral observer. I have used conda for nearly a decade, brought users and teams to it, contributed across the ecosystem, and I serve the conda infrastructure team. Some of the work below I coauthored with Jannis Leidel, including the Conda Is Not PyPI series and conda-meta-mcp. That is why I do not find the simple “old tool vs new tool” story useful.

The comparison shows ecosystem phases: bootstrapping, carrying infrastructure, standardizing behavior, and rediscovering product taste through new clients.

First, define the battlefield

There are two different meanings hidden in the word conda.

One meaning is the conda command line tool, implemented mostly in Python, historically shipped through Anaconda and Miniconda, and used by millions of people.

The other meaning is the conda package ecosystem: package formats, channels, repodata, solvers, virtual packages, recipes, lockfiles, build systems, metadata, defaults, conda-forge, bioconda, and all the conventions that enable tools to install coherent software environments. That distinction matters.

Pixi relates to the conda ecosystem the way pip relates to PyPI: it consumes it, it does not compete with it. Pixi installs conda packages and uses the same broad idea of a multi-language user-space distribution. The real comparison is not conda ecosystem vs pixi. It is conda client vs pixi client, on shared conda ecosystem standards.

That changes the conclusion:

If pixi succeeds, that is not automatically a loss for conda. It can be a success for the conda ecosystem.
And if the conda client improves because pixi makes the gaps obvious, that is also a success for the conda ecosystem.

But that reframing only holds under one condition: the ecosystem has to be specified somewhere other than inside one client. For most of conda’s history, it was not.

Why Python was the right start

Python was never only about runtime speed. It became popular because it is excellent glue: it connects fast lower-level libraries written in C, C++, Fortran, Rust, and other languages. That is one reason Python became so important in science, data analytics, machine learning, automation, and infrastructure scripting.

Conda being written in Python makes perfect sense. It emerged from the Python world. It needed to experiment, expose behavior as importable libraries, and grow around scientists, developers, packagers, and automation.

That also matters for a reference client: readable code, importable behavior, scriptable internals, and low-friction experimentation help an ecosystem understand itself. Python was not a mistake just because Rust tools now feel nicer in the terminal.

Conda was never just a Python package manager

The second mistake is thinking conda is basically pip with environments. It is not.

Conda packages are closer to distribution units than language packages. A conda environment can contain Python, R, C/C++ libraries, Fortran runtimes, compilers, CUDA components, CLI tools, data files, headers, shared libraries, and Python packages, all solved together. Conda became important because it modeled coherent software stacks in user space, across languages and platforms, without needing root.

That is also why it became complex. A user-space distribution inherits distribution-level concerns: ABI compatibility, build variants, virtual packages like __glibc and __cuda, platform metadata, repodata, channel priority, compilers, run exports, lockfiles, and migration infrastructure.

Conda’s strength and conda’s weight come from the same place.

The problem was not Python. The problem was debt.

Conda had real speed problems for a long time. Solving got much better with libmamba, and modern conda can solve fast. But solve time is only one kind of speed. Users also feel startup delay, shell activation cost, metadata fetching, install and extract time, progress feedback, and general CLI responsiveness. Pixi is strong across more of those dimensions and helped push ideas such as lockfile-first and sharded repodata into the wider ecosystem.

Stating “conda became slow because of Python” is too shallow. Projects get slow when they accumulate technical debt, historical behavior, compatibility promises, weak boundaries, special cases, and too much fear around changing core behavior. That can happen in Python. It can happen in Rust, too.

Successful tools also increase distance over time. There is a distance between the user pain and the person changing the code. There is a distance between a design decision made ten years ago and the maintainer trying to understand it today. There is a distance between “we need this feature” and “we can safely release this feature”.

That distance is not a moral failure. It is what happens when a tool becomes infrastructure.

Conda had to carry a lot:

Old behavior that real users relied on.
Many workflows that grew organically.
A central role as the de facto reference implementation.
A large user base where breaking changes are expensive.
Core code that became harder to touch safely.

At some point the issue stops being language first. It becomes architecture, testability, release confidence, and product clarity.

Mamba and Pixi changed more than speed

Mamba mattered because it proved the experience could be dramatically faster. The libmamba solver later becoming available in conda was an important ecosystem moment: a faster implementation did not merely sit outside and criticize, it fed back into the original client. That is a healthy pattern.

Pixi pushes further.

Pixi is built on Rattler, Rust implementations of conda ecosystem primitives. It is distributed as a fast single binary. It is project-centric. It uses {pyproject, pixi}.toml. It treats the lockfile as part of the normal workflow. It has tasks. It supports multiple environments. It integrates PyPI dependencies through uv. It defaults to conda-forge and feels designed around modern developer expectations.

That is why people like it. Not only because it is fast in benchmarks, but because it feels fast: it communicates. It feels safe because the project has a manifest and lockfile. It feels obvious because pixi run, pixi add, tasks, and local project environments match how many people think about modern development.

The product is opinionated in a useful way, and conda can learn from that without becoming pixi.

Lockfiles are not a side quest

Pixi’s biggest product decision may be that lockfiles are not treated as an optional afterthought. In modern development, lockfiles are basic infrastructure. They separate intent from resolution.

The manifest says what you want.
The lockfile records what you got.

That distinction matters for reproducibility, CI, collaboration, debugging, auditing, and supply chain work.

Yet lockfiles are only as strong as the bootstrap path that interprets them.

Classic conda workflows often center around environment.yml. That file is useful, but it is not a complete lockfile. If you solve it again next week, the ecosystem may have changed. That may be what you want, but it is not reproducible.

Pixi made the lockfile part of the default path. You add a dependency, the lockfile changes. You commit both. The tool nudges you toward the safer workflow, and people usually do what the tool makes easy.

The broader conda ecosystem now standardizes lockfile formats through CEPs. That is exactly the right direction. The goal is not “Pixi has lockfiles and conda does not”. The stronger path is ecosystem-level lockfile standards that multiple clients can produce, consume, inspect, update, and audit.

However, supporting a lockfile format is not the same as being lockfile-first. Exporting a lockfile from an existing environment is useful, but it is different from declaring intent in a manifest, solving from repodata, writing the lockfile, and installing from it. First-class lockfiles are a native flow: manifest to solve to lockfile to install.

Pixi is ahead in user experience here, and that is the lesson the ecosystem can and should absorb.

Plugins helped conda survive

Conda’s plugin architecture was a good move. It made the libmamba solver integration possible without rewriting everything at once, lowered the barrier to experimentation, and gave focused projects room to evolve outside the most sensitive core.

Plugins are a pressure-release valve for large projects. Yet they are not magic. The hard question is when something is truly optional, and when it is core behavior living in a plugin because the core became too hard to change. A default solver, lockfile workflow, or modern project workflow shapes what users think the tool is.

Lockfiles make this sharper. Pixi as a single binary has a simple starting point: hash the binary and you know what you started with. A Python-based conda installation with optional plugins has more moving pieces. If the first step is “install this plugin outside the lockfile so the tool can understand the lockfile”, the bootstrap chain starts outside the cryptographic record. The environment may still be practically reproducible, but the trusted starting point is not fully covered.

There is a related versioning question. If important behavior lives in optional plugins, what does a conda version mean? The core client, solver plugin, lockfile plugin, reporter backend, and shell helpers can all have different versions. For a trusted starting point, users often need the combined state: this exact client, plugin set, and versions.

That is why the bootstrap problem is not cosmetic. Projects like conda-ship and conda-express point toward an interesting middle ground. conda-ship is the generic builder: it turns a solved, locked conda environment into a small single-binary runtime. conda-express is one downstream distribution built that way, shipping the rattler-powered cx binary that bootstraps a lockfile-defined base environment. Python conda stays extensible, standards-aligned, and plugin-capable, while the binary moves atomically from one locked state to the next instead of protecting a mutable base after the fact.

That also addresses one of the oldest sources of conda pain: users turning base into a general-purpose workspace. Once user packages and conda’s own dependencies mix there, conflicts are inevitable. A locked base says: this is the toolchain root, not a project environment.

Therefore, the answer is not “plugins are bad”. It is more precise: plugins are excellent for exploration, incubation, integration, and optional behavior. When a workflow becomes central, there is a strong case for making it first-class.

Conda as reference implementation

If the ecosystem has multiple clients, what can the conda client be? One possible answer is: the reference implementation.

A reference, not the definition

Historically the conda and conda-build code were the standard: behavior was the spec, and other clients had to reverse-engineer it. After the CEPs, written specifications become the reference, and conda becomes a reference implementation rather than the definition. That is healthier: the spec is what everyone agrees on, and the client is one readable expression of it.

That does not mean slow, boring, or keeping every old feature forever. It means conda can be the clear, inspectable, standards-aligned implementation of core behavior: a place where the ecosystem sees what the standards mean in practice, and where old accidental behavior is standardized, deprecated, or removed. It does not have to be the smallest or fastest client; its job is to make core behavior understandable, which requires discipline. A reference implementation works best when it does not become a museum.

There is a pattern in other software ecosystems: a large successful product grows until its core idea is hard to see, then someone writes a tiny Python version that reveals the algorithm again. Later, others rewrite that core in Rust, Go, Zig, or C for a different constraint: one binary, tiny memory use, embedded deployment, startup time, or supply-chain simplicity. That sequence is not failure. It is an ecosystem learning its own shape.

For conda, this suggests a useful distinction. The conda client could become the modern, readable, standards-aligned reference implementation of the ecosystem, while pixi stays the sharp Rust product experience. And there may still be room later for an even smaller client, maybe in Zig or another systems language, that implements a narrow standardized core with a tiny trusted binary.

That is where Python still has a strong role.

Where Python still fits

Python is inspectable, scriptable, and easy to embed in adjacent automation. conda-meta-mcp, a project I work on, is one example: it wraps existing conda libraries to expose structured package metadata to AI agents instead of forcing them to scrape terminal output. AI agents, CVE scanners, SBOM tools, package inspectors, and search tools all benefit from that kind of structured access.

That is not the same job pixi is optimized for. Pixi can be sharp. Conda can be clear. The ecosystem needs both qualities.

Standards are the real win

The most important thing that happened because of reimplementations is not only speed. It is standardization.

For a long time, much of the conda ecosystem was defined by behavior in conda and conda-build. If you wanted to build another client, you had to reverse-engineer intent from source code, tests, issue comments, and observed behavior. That is fragile. Mamba, Rattler, pixi, and other ecosystem work created pressure to write things down. That pressure is good.

The Conda Enhancement Proposal process turns implicit behavior into public standards. In early 2026 the community approved ten foundational CEPs in one batch, covering core pieces such as MatchSpec, virtual packages, build provenance, the structure of conda environments, versions, package contents, package file formats, repodata, the conda-lock.yml lockfile, and channeldata.

CEP 30 on virtual packages is a good example. Virtual packages such as __glibc, __cuda, __osx, and __archspec are host facts exposed to the solver, not files installed into an environment. If conda, libmamba, and Rattler disagree on those facts, the same environment request can mean subtly different things in different clients. Standardizing that behavior makes multiple implementations safer.

That changes the ecosystem: once standards exist, multiple clients stop being a fragmentation threat and start being a strength.

Standards break the zero-sum logic: investment in one client can benefit all clients when it strengthens shared behavior, metadata, and infrastructure. That creates stability and trust, both prerequisites for ecosystem growth.

Then conda, mamba/micromamba, pixi, and future tools can compete on user experience, performance, distribution model, project workflow, and integration without disagreeing about what a package is.

This also enables tools that are not package managers at all: scanners, auditors, metadata services, MCP servers, package search, dependency graph analysis, automated update systems, and build provenance tooling.

Some internal standards matter most because they connect to external ones. Regulations like the EU Cyber Resilience Act make SBOMs mandatory, and an SBOM inventories a package’s components in a standard format like CycloneDX or SPDX. Much of the value then comes from identifying each component with an external scheme such as purl: a conda package can record both its own conda identity and the upstream package it repackages, which is exactly what links it to cross-ecosystem vulnerability data and unlocks supply-chain analysis and CVE scanning, curation, and mitigation. With software supply-chain attacks now routine, that visibility is more important than ever. That is why standardization is not just an internal exercise: it is what lets the whole ecosystem meet global requirements.

That is the strongest argument for pixi existing.
It does not replace conda.
Pixi helps to force the ecosystem to become explicit enough that replacement of conda is not the question anymore.

The underrated engineering skill is sensing

There is a word I keep coming back to here: sensing. Good tools require it.

What good sensing notices

Sensing what users actually do. Sensing where the friction is. Sensing what users cannot articulate yet, because some needs only become obvious once the tool exists. Sensing what newer tools made possible. Sensing what is product polish and what is core architecture. Sensing what is now technically possible. Sensing when an old design is still valuable and when it has become a tax. Sensing not only what to build, but how to get there.

Pixi sensed several things correctly, and the conda team has since named similar instincts. Dan Yeaw’s vision for the conda CLI frames a good tool as fast, trusted, and delightful, leaning on the same generation of tools users now measure conda against:

Users like single binaries.
Users like project-local workflows.
Users expect lockfiles.
Users want task runners.
Users compare every CLI to uv, ruff, ripgrep, gh, bat, and other modern tools.
Users experience silence as slowness.
Users want defaults that feel safe without reading a manual first.

That kind of sensing is not just product management. It is engineering context.

Keeping the sensing loop alive

The best teams keep investing in it in their own way. They stay close enough to users to feel friction, close enough to the code to understand constraints, and close enough to adjacent tools to notice when expectations change.

For sensing to work, the “what” and the “how” cannot be separated. A team that owns only the “what” designs things that sound right but do not fit the architecture; a team that owns only the “how” polishes internals while missing the experience that should guide them. Product taste, user feedback, architecture, implementation, and release responsibility need enough overlap to inform each other. This is not specific to conda: young tools keep these close together, while mature infrastructure passes every decision through a long chain of translations where information gets filtered at each boundary. That is how tools lose taste.

Outside input still matters, but it works best when it helps the team build its own sensing. If a team receives conclusions before it has the context to evaluate them, the easier path is often to consume the input. Over time, that can prevent the sensing loop from forming at all.

Consuming input can feel easier than developing the judgment that would make the input useful.

Sensing is really about preserving context: why old decisions were made, which users depend on them, what changed around them, and which new possibilities are now available. Without that context, contributions become guesses. With it, even small changes can be highly valuable.

Learn From Pixi Without Copying It

There is a danger in learning from pixi badly. The goal is not for conda to become “pixi, but slower and with more compatibility constraints”. That would be the worst version.

Conda can learn from pixi’s defaults, communication, project workflows, lockfile-first thinking, and product coherence. But copying visible features is not the same as understanding why they work. The harder task is to maintain the sensing loop that produces good decisions in the first place.

One useful word here is companion. Some modern Rust tools do not need to erase older Python tools to matter; ruff can sit next to pylint, flake8, and related tooling while changing expectations around speed and coherence. In the same way, a conda-ship-built binary like cx can be understood as a locked conda starter: a small companion that strengthens the bootstrap path instead of replacing the whole client.

If a small companion can strengthen the bootstrap path, the larger question is what the conda client around it should be. The reference-implementation job described earlier is its core; the concrete commitments around it are what make it distinct: excellent Python APIs for ecosystem tooling, first-class lockfiles, metadata, and provenance, plugins used for genuine extension points rather than as a hiding place for core behavior, and dependability for named environments, enterprise, CI, HPC, and long-lived infrastructure.

Some of this already exists. conda-lockfiles and conda-self are now part of the conda project itself; conda-lockfiles adds support for multi-platform lockfile formats including conda-lock and pixi.lock. Other pieces are still incubating: conda-workspaces explores a pixi-like project workflow with project-scoped environments, tasks, and reproducible lockfiles in conda.toml. Together they show where the reference-client shape is being worked out in practice.

That is not a small job. But it is also not the same job as pixi.

Where I would use what

Tool choice depends on the shape of the work.

Work shape	Reach for	Why it fits
New project needing reproducibility, tasks, and a clean project-local workflow	pixi	Especially data science, ML, CUDA, robotics, bioinformatics, scientific software, and other compiled-dependency work.
Long-lived named environments, debugging multiple local checkouts together, enterprise workflows, existing infrastructure, or Python-level conda APIs	conda	pixi’s project-local model is less natural for the centrally located, reused-across-checkouts workflow these rely on.
Pure-PyPI library development	uv (or pixi, carefully)	pixi can duplicate dev dependencies across `pixi.toml` and `pyproject.toml`; `uv` currently has more contributor mindshare here.
CI and containers	It depends	pixi’s lockfile-first flow is attractive; `micromamba` is a handy small bootstrap; `conda` fits when it is the org standard or plugin/API integration matters.

The important point is not to pretend one tool needs to erase the others. The important point is to make the ecosystem standards strong enough that choosing a client is a workflow decision, not a package compatibility gamble.

The ecosystem can embrace both

There is space for both conda and pixi. Not because duplication is always good, but because different implementations reveal different truths.

Conda reveals what it means to be infrastructure. It carries history, compatibility, policy, and reference behavior. It shows where the ecosystem came from and what must be specified carefully.

Pixi reveals what the ecosystem feels like when you revisit it with modern CLI expectations, Rust performance, project-local workflows, lockfiles, and fewer historical constraints.

The tension is useful. Without conda, pixi would not have the ecosystem it installs from. Without pixi, conda would have less pressure to become fast, trusted, delightful, and explicit. Without standards, both would eventually drift, and the ecosystem would not be able to grow in a sustainable and trustworthy way.

The strongest future is shared standards, multiple clients, reusable libraries, clear metadata, and enough discipline to keep innovation flowing back into the ecosystem instead of splitting it.

Final takeaway

conda vs pixi is more than a fight between two package managers. It is a continuation of conda’s middle path: not a language registry, not a container or full system manager, and not a single-client monoculture. The open question is whether the conda ecosystem can keep walking that path, becoming more standardized, inspectable, modular, and composable, so that more tools strengthen it and more users find their way in.

Yes, I think the conda ecosystem can keep moving in that direction. Not by choosing one winner, but by making every strong implementation feed the shared ecosystem back.