SciPy 2026

login

Scipy, Numpy, Xarray and Python all have a pixi.toml. Why?
.ical
2026-07-16 –, Memorial Hall

After 3 years, Pixi is widely adopted in the scientific Python ecosystem. At SciPy 2026, we want to show why.

Scientific Python has specific challenges that Pixi can solve well; a lot of our beloved packages contain C, C++, Rust, CUDA or even Fortran code. With Pixi, a single tool can install the compilers, different Python versions and other build tools in one go, thanks to piggy backing on the years of development that the Conda ecosystem has seen.

Thanks to Pixi’s task system and native multi-platform capabilities, the contributor experience is also enhanced. Daunting tasks like running CMake, installing the correct Rust version or C++ compilers are all hidden away behind a magical: pixi run foobar.

Are you interested to see how you could improve your own workflow and learn from what these big open-source projects are doing? Then you should join this talk! You'll be amazed by what is possible these days.

Pixi is getting widely adopted in the Scientific Python community. Projects such as Python itself, NumPy, SciPy, cuda-python and Xarray have a pixi.toml file in their repository. Through the heroic work of Lucas Colley and other contributors, even CPython has a pixi.toml now. In this talk we want to explain what this means and what improvements this brings for users and contributors!

Pixi helps for the following reasons:

Primarily Pixi creates one or more environments on the developer machine containing Conda and Python packages (under the hood, uv is used to resolve and install Python packages). All packages are added to a lockfile that is used to recreate environments in a reproducible way. Pixi can bootstrap the entire development environment in seconds, including a consistent set of compilers, shared libraries, and other low-level pieces.

Pixi’s task system makes it easy for contributors (old and new) to get started. Developers can add tasks such as lint, build, start, … to the pixi.toml file. This simplifies the commands that need to be remembered when starting out with a project. It makes it also easy to have “portable CI”. Pixi can run these tasks on Github, Gitlab, CircleCI on any operating system.

Advanced use cases:

The pixi.toml files in the CPython project are mainly used for advanced tasks such as building CPython itself with address sanitization turned on. Thanks to Pixi, downstream projects (Numpy, SciPy, …) can depend on CPython from source. This is enabled by the powerful pixi build. Pixi build brings building projects from source into packages to Pixi itself. Usually, package consumers and builders are quite disjoint in the Conda ecosystem! With Pixi you can now run crazy things like pixi global install --git https://github.com/python/cpython --subdir Tools/pixi-packages/asan python to obtain the latest version of Python built from main installed globally on your system.

Our talk will also cover the following topics:

  • What is Pixi and the conda-ecosystem?
  • How do these big open source projects use Pixi?
  • What steps can one take to benefit from Pixi in their workflow?

Pixi itself is open source under the BSD3 Clause, written in Rust and embeds astral-sh's uv to help with combining conda and Python packages into one virtual environment. Pixi is built on the rattler base library that is used in all sorts of different conda tools and is also making it's way into conda and conda-build.

Some of the previously mentioned projects started to use Pixi because of one specific feature: cross-platform source building of Git packages into a local development environment. This experience is similar to depending on a package from source in a python environment but Pixi also takes care of all the complex compiler and low level system libraries that a user might require to have on their system. This feature has proven very useful for testing the latest (pre-release) versions of projects in their upstream environments.

These workflows come with a few key steps:

  • Building packages from source code, from git or paths
  • Installing virtual environments on any platform, Windows, macOS, Linux
  • Reproducible environments with lockfiles
  • Cross-platform Makefile-like task system with Pixi tasks
  • Deployment with easy to share artifacts

Relevant links:

The speaker's profile picture
Ruben Arts

Ruben is part of the Prefix.dev core team, builing Pixi and other tools in the package management space. Originally he's a Robotics engineer working on industrial robots, but quickly figuring out that solving development and deployment problems were one of the bigger issues that robotics developers had to deal with. Joining Prefix.dev allowed him to focus on improving the UX/DX of a large group of software engineers. Over the years he's been doing multiple talks and workshops on how to properly manage software and development workflows.

This speaker also appears in: