# pixi: a conda-based package manager with a Cargo-style CLI

> pixi installs conda packages per project or system-wide, keeps a lock file, and targets Python, C++ and R on Linux, macOS and Windows. Here is how it works, how to install it, and where it stops being the right tool.

**prefix-dev/pixi** — Powerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.

- Repository: https://github.com/prefix-dev/pixi
- Website: https://pixi.sh
- Stars: 7,803 · Forks: 570
- Language: Rust
- License: BSD-3-Clause
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/prefix-dev-pixi

## What pixi is for, and who ends up using it

The README describes pixi as a cross-platform, multi-language package manager and workflow tool built on the conda ecosystem, with an experience similar to cargo or npm. That framing matters more than the package-manager label. The project is aimed at people who want conda's binary package availability but not conda's environment model, where environments live outside the repository and get activated by hand. In pixi, the project directory is the unit of work: you get a manifest, a lock file and an environment that belongs to that directory.

The multi-language claim is the second half of the pitch. The highlights list Python, C++ and R through Conda packages, and the examples directory backs that up with folders such as cpp-sdl, geos-rs, r, qgis and opencv. A team that ships a Python service with a compiled C++ dependency, or an R analysis alongside Python tooling, can express both in one manifest instead of maintaining a conda environment file plus a separate toolchain install. If your work is a single pure-Python library with no compiled dependencies, pixi is more machinery than the problem needs.

## How the manifest, lock file and solve actually fit together

The architecture visible in the repository is a Rust workspace. Cargo.toml declares members = ["crates/*"] with default-members = ["crates/pixi"], so the CLI is one crate among many, and the README states the whole thing is built on the rattler library. That is the dependency solver and package-fetching layer inherited from the conda world, which is why pixi can consume conda channels at all.

The user-facing mechanism is the lock file. The highlights say pixi always includes an up-to-date lock file, and the repository root contains pixi.lock next to pixi.toml, so the tool locks itself the same way it locks your projects. The flow is: you declare dependencies in pixi.toml, the solver resolves them against the configured channels, and the result is written to pixi.lock. Subsequent installs read the lock rather than re-solving, which is what makes the same revision reproducible on another machine. The README's status section says the team is working to keep file-format changes compatible with previous versions, which is a statement about intent, not a compatibility guarantee you can build tooling against.

One design consequence worth naming: because resolution happens against conda channels, your reproducibility is bounded by what those channels still serve. A lock file pins versions and hashes, but it does not host artifacts.

## Installing pixi on Linux, macOS and Windows

The README gives a shell installer for macOS and Linux. It downloads the latest pixi, extracts it, and moves the binary to ~/.pixi/bin, creating that directory if needed. The same section notes the script updates ~/.bashrc to add ~/.pixi/bin to PATH, so you may need to restart the terminal or source your shell.

```bash
curl -fsSL https://pixi.sh/install.sh | sh
# or with brew
brew install pixi
```

On macOS the README points out that zsh is the default login shell since Catalina and offers the zsh variant of the same command:

```zsh
curl -fsSL https://pixi.sh/install.sh | zsh
```

On Windows the documented route is PowerShell. The README notes you may need to run it as an administrator, and that changing the execution policy is what allows running a script from the internet. It also shows how to inspect the script first, which is the right habit for any pipe-to-shell installer.

```powershell
powershell -ExecutionPolicy ByPass -c "irm -useb https://pixi.sh/install.ps1 | iex"
```

There is also a winget package and distro packages. The README lists winget install prefix-dev.pixi, pacman -S pixi on Arch, and an Alpine Edge package installed via apk after enabling the testing repository.

```shell
winget install prefix-dev.pixi
```

After install, the README documents shell completion for bash, zsh, PowerShell, Fish, Nushell and Elvish. For bash it is a single eval line appended to ~/.bashrc:

```bash
eval "$(pixi completion --shell bash)"
```

That is where the README stops. It does not walk through creating a first project, so the first real use is not spelled out in the README; the examples directory and pixi.sh are where the project points for that.

## Where pixi is the wrong tool

The most concrete limitation is stated by the project itself: the README's status section lists build-and-publish as a feature envisioned for upcoming releases, along with dependencies from source and more powerful global installation. Those are not shipped capabilities, they are roadmap items. If your workflow ends with publishing a conda package, pixi as documented here is not the tool that does that step.

A second constraint is the version range. The current version in pyproject.toml is 0.81.0, and the recent releases run v0.79.0 through v0.81.0. The README says pixi is ready for production and that the team works to keep file-format changes compatible, but a pre-1.0 tool means the manifest and lock schemas can still move. Anyone writing a parser for pixi.toml or generating pixi.lock from another system is building on a format the project has not frozen.

The third case is scope. pixi resolves conda packages. If your dependency graph is PyPI-only and your team has already standardized on a different lock-file workflow, adding a conda-channel layer buys you compiled-package coverage you are not using, at the cost of a second package ecosystem to reason about. The README does document PyPI-oriented examples, including pypi, pypi-custom-registry, pypi-find-links and pypi-source-deps, so mixing is possible, but the mixing is exactly the complexity you are choosing.

## How pixi differs from uv

The comparison people search for is uv against pixi, and the difference is upstream of the CLI. uv resolves Python packages from PyPI and installs wheels or sdists. pixi resolves conda packages through rattler and can additionally pull from PyPI, which is why the examples directory carries both pypi and conda-oriented examples rather than one or the other.

That changes what you can depend on. A C++ library such as SDL, or a geospatial stack like GEOS or QGIS, is available as a conda package with its native dependencies already resolved; the cpp-sdl, geos-rs and qgis examples exist precisely because those are not PyPI-shaped problems. On the other side, a pure-Python project gains nothing from the conda channel layer and inherits a larger dependency universe plus a second package index to configure.

The interface difference is smaller than the ecosystem difference. Both aim at a lock file and a fast CLI. The decision is really about whether your dependency graph contains non-Python artifacts that need binary packaging, or whether it is Python all the way down.

## Maintenance, releases and what the licence permits

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent: v0.79.0 on 2026-09-03, v0.80.0 on 2026-09-07 and v0.81.0 on 2026-09-15, roughly weekly. The workspace pins rust-version = "1.90" and edition = "2024", so building from source requires a recent Rust toolchain. If you consume release binaries or a distro package, that pin does not affect you; if you vendor or patch pixi, it does.

The upgrade cost is mostly the lock file. Because the README describes ongoing work to keep file formats compatible, a version bump can change the manifest or lock schema, and the practical check after upgrading is whether pixi.lock still resolves and whether any schema keys moved. The repository carries a schema directory, which is the thing to diff when you want to know what changed in the manifest format rather than guessing from the changelog.

pixi is BSD-3-Clause, stated in both the README badge and the workspace Cargo.toml. That is a permissive licence, so redistribution and modification are allowed with the usual conditions around copyright notice and the licence text. This is a description of the licence identifier, not legal advice; if you are embedding pixi in a product, read LICENSE and consult your own counsel about notice requirements.

## Conclusion

Adopt pixi if you want conda package availability with a lock file and a CLI that behaves like cargo, and if your team already tolerates conda channels. Do not adopt it if you need a stable 1.0 file format for tooling you write yourself, since versions are still in the 0.8x range, or if your stack is pure Python and already resolved by another lock-file tool. Before committing, run pixi init in a scratch directory, confirm the platform entries and channels in pixi.toml are the ones you expect, and check that the generated pixi.lock resolves for every platform you ship to.

## FAQ

### What is Pixi for Python?

pixi is a cross-platform package manager and workflow tool built on the conda ecosystem, and the README lists Python among the languages it supports through Conda packages. It gives Python projects a Cargo-like CLI, a manifest and a lock file, and it can also install tools per-project or system-wide.

### How do I uninstall Pixi?

The README documents installation but does not describe an uninstall procedure, so there is no documented command to reverse the install script. What the README does say is that the installer places the pixi binary in ~/.pixi/bin and adds that directory to your PATH, which tells you what an uninstall would have to remove.

### What are the key differences between UV and Pixi?

pixi resolves conda packages through rattler, the library the README says it is built on, and its examples cover C++, R and geospatial stacks such as QGIS and GEOS. uv works from PyPI. The practical difference is that pixi can pull non-Python native dependencies from conda channels, which a pure-Python project does not need.

## Sources

- [License: BSD-3-Clause](https://github.com/prefix-dev/pixi/blob/main/LICENSE)
- [prefix-dev/pixi on GitHub](https://github.com/prefix-dev/pixi)
- [Project website](https://pixi.sh)
- [README](https://github.com/prefix-dev/pixi/blob/main/README.md)
- [Releases](https://github.com/prefix-dev/pixi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prefix-dev-pixi