Pixi adds non-Python deps to Python notebooks

Marimo's notebook sandboxes now support Pixi, letting standalone notebooks record Conda and PyPI requirements alongside their code, the marimo team announced. The integration, built with the Pixi team, allows a notebook to declare non-Python dependencies such as ffmpeg and pytorch-gpu for Pixi to install, so anyone with Pixi installed can open the notebook in marimo's interactive editor or run it as a script. The work also improved marimo's sandbox experience for uv users.

marimo’s notebook sandboxes https://docs.marimo.io/guides/package management/sandboxes/ now support Pixi https://pixi.prefix.dev/ . You can build and share standalone notebooks with requirements from both Conda https://conda.org/ and PyPI https://pypi.org/ recorded alongside the code. For example, this notebook uses marimo’s reactivity to drive GPU-accelerated transcription with Whisper https://github.com/openai/whisper : When you choose a recording, marimo reruns Whisper to transcribe it. Whisper needs FFmpeg https://ffmpeg.org/ to decode the audio and PyTorch https://pytorch.org/ to run the model, so the notebook declares ffmpeg and pytorch-gpu pixi-dependencies for Pixi to install. Since these requirements are recorded in the notebook, anyone with Pixi installed https://pixi.prefix.dev/latest/installation/ can open it in marimo’s interactive editor to edit the code and interact with its outputs: pixi exec marimo edit --sandbox=pixi https://raw.githubusercontent.com/marimo-team/marimo/main/examples/misc/pixi whisper.py Or execute the notebook as a Python script from the terminal, without opening the editor: pixi run --script https://raw.githubusercontent.com/marimo-team/marimo/main/examples/misc/pixi whisper.py We built this integration with the Pixi team, improving marimo’s sandbox experience along the way for everyone—including uv users. The Pixi integration builds on how marimo’s sandbox mode https://docs.marimo.io/guides/package management/sandboxes/ turns a notebook’s requirements into a running environment. Consider a Python program that uses Polars. python import polars as pl pl.DataFrame { "city": "London", "Paris", "Berlin" , "temperature": 18, 22, 20 , } This program depends on Polars, which must be installed in the Python environment running it. Otherwise, the import raises a ModuleNotFoundError . Tools like uv https://docs.astral.sh/uv/ and Pixi https://pixi.prefix.dev/ automate the setup. Instead of writing out a sequence of setup commands, you provide a manifest : a file listing the program’s dependencies and Python version requirements. The tool reads that file, prepares an environment, and runs the program inside it. For a project https://docs.marimo.io/guides/package management/projects/ containing related scripts and modules, it is common to keep the manifest in a separate file, such as pyproject.toml https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ . Package managers use that manifest to prepare an environment those programs share . Both scripts share one environment. For a standalone script, the Python file itself can serve as the manifest. PEP 723 https://peps.python.org/pep-0723/ defines a comment format for recording requirements alongside the code, allowing a package manager to prepare an environment only for that script. Each script has its own environment. We can give our Polars example its own manifest by adding a comment at the top of the file. /// script requires-python = " =3.12" dependencies = "polars =1,<2" /// import polars as pl pl.DataFrame { "city": "London", "Paris", "Berlin" , "temperature": 18, 22, 20 , } With the requirements recorded alongside the code, the script can be shared as a single file. uv https://docs.astral.sh/uv/guides/scripts/ or Pixi https://pixi.prefix.dev/latest/python/scripts/ can prepare its environment and run it without separate setup instructions. Every marimo notebook is a Python script https://docs.marimo.io/guides/scripts/ , so the same two approaches apply. A notebook can share a project’s environment or record its own requirements inline. Sandbox mode https://docs.marimo.io/guides/package management/sandboxes/ builds on package managers’ script support to manage the notebook’s environment from those inline requirements. As you develop the notebook, you can install or remove packages through the Packages panel, or accept marimo’s prompt to install a missing dependency https://docs.marimo.io/guides/package management/installing packages/ when an import fails. marimo records those changes in the notebook’s inline metadata polars-dependencies and synchronizes the running environment. python import polars as pl pl.DataFrame { "city": "London", "Paris", "Berlin" , "temperature": 18, 22, 20 , } With the requirements saved in the notebook, you or a collaborator can reopen it in a sandbox with uvx marimo edit --sandbox notebook.py Or run it as a script with uv run notebook.py Python packages are often only part of what a notebook needs to run. As a cross-language package manager, Pixi can draw on the Conda ecosystem to bring the rest of those dependencies into the same environment. Here are a few examples of what that makes possible: Declare ffmpeg as a Conda dependency ffmpeg-dependencies , and Pixi makes FFmpeg https://ffmpeg.org/ available to call from Python: python import subprocess output = subprocess.check output "ffmpeg", "-version" , text=True output.splitlines 0 ffmpeg version 9.0.2 Copyright c 2000-2026 the FFmpeg developers Declaring pytorch-gpu guarantees a CUDA-enabled build of PyTorch https://pixi.prefix.dev/latest/python/pytorch/ installing-from-conda-forge , with no extra indexes to configure. This cell checks that the installed build has CUDA support: python import torch torch.backends.cuda.is built True The Python package rpy2 https://rpy2.github.io/doc/latest/html/overview.html needs an R installation to call R functions. Pixi provides the runtime alongside the Python package: python import rpy2.robjects as ro summary = ro.r "summary iris$Sepal.Length " dict zip summary.names, summary { "Min.": 4.3, "1st Qu.": 5.1, "Median": 5.8, "Mean": 5.843333333333334, "3rd Qu.": 6.4, "Max.": 7.9, } With Pixi support, we can declare both PyPI requirements marimo and rpy2 r-dependencies and Conda requirements r-base r-dependencies in the notebook. Opening the notebook in a Pixi sandbox installs both into one environment. Combining PyPI and Conda packages in one notebook opens up interactive analyses that span languages and tools. For example, moving a slider can filter a table in R https://github.com/marimo-team/marimo/blob/main/examples/misc/pixi r.py and update marimo’s dataframe viewer: Try it out yourself: pixi exec marimo edit --sandbox=pixi https://raw.githubusercontent.com/marimo-team/marimo/refs/heads/main/examples/misc/pixi r.py marimo’s sandbox mode was originally built around uv https://docs.astral.sh/uv/ , whose speed and early support for PEP 723 made per-notebook environments practical. Seeing how sandboxing made notebooks easier to author, share, and run, we wanted to bring the same experience to users from the scientific computing community who rely on Pixi for dependencies beyond Python. Over the past two SciPy conferences and a jigsaw puzzle https://github.com/prefix-dev/pixi/issues/6632 issuecomment-5037377958 , we got to know the Pixi developers and began discussing how to bring Pixi’s capabilities to standalone Python scripts. We advocated for building on PEP 723 https://github.com/prefix-dev/pixi/issues/3751 issuecomment-2898979448 , keeping Python requirements in the standard fields and adding Pixi-specific configuration under tool.pixi . Together, we landed support upstream https://github.com/prefix-dev/pixi/pull/6648 for running scripts, managing their dependencies, and locking their environments. With Pixi’s script support in place, we could rework marimo’s sandbox implementation https://github.com/marimo-team/marimo/pull/10728 around a common model for both backends. Previously, starting a sandbox and changing its packages followed separate paths, which could let the running environment diverge from the notebook’s recorded requirements. Both operations now use the notebook’s manifest and the selected package manager’s script commands to prepare and synchronize its environment. Those commands respect tool-specific configuration https://docs.marimo.io/guides/package management/sandboxes/ tool-specific-configuration such as package indexes and sources, improving correctness for existing uv sandboxes as well as enabling Pixi. The package manager uses the same notebook metadata to prepare the environment whether you work interactively in marimo or run the file as a script. Revisiting sandboxing also let us improve setup and error recovery for both Pixi and uv. The editor now opens while the environment is prepared, and the Packages panel https://docs.marimo.io/guides/package management/ shows progress and errors. Edit manifest lets you change the notebook’s requirements and package manager settings directly. If setup fails, you can fix the manifest and retry without restarting marimo. The panel also tells you when a dependency change needs a kernel restart. Try one of the notebooks above, or add a Pixi sandbox to your own notebook https://docs.marimo.io/guides/package management/sandboxes/ conda-packages-with-pixi . Pixi support is available in marimo 0.25.0 https://github.com/marimo-team/marimo/releases/tag/0.25.0 and later. On a personal note, I’ve really enjoyed getting to know the Pixi team and working with them on this feature. The opportunity to build bridges between open-source projects is a big part of what brought me to marimo https://trevorma.nz/blog/im-joining-marimo , and I feel fortunate to have found work that keeps me connected to these communities.