Experimental: this may still change, see #108.
A Pixi environment can have Python and its packages next to R and its packages, in the same pixi.lock, so a collaborator gets the same Python stack too. R uses it through reticulate.
Set it up
or, for a new project, use_pixi(python = TRUE). This adds Python, reticulate, and what reticulate needs to use the environment’s Python, and points reticulate at it. Restart R afterwards.
Then add Python packages. Most are on conda-forge:
pixi_add("conda::numpy")For those that aren’t, such as pydytuesday (TidyTuesday’s data, for Python), add them from PyPI:
pixi_add("pypi::pydytuesday")Use them from R as usual:
numpy <- reticulate::import("numpy")What it sets up
-
RETICULATE_PYTHON, inpixi.toml’s[activation.env], points reticulate at the environment’s Python. Without it, reticulate makes a Python of its own, which doesn’t have the project’s packages. It applies to R started withpixi run, and to R started by an IDE, through the project’s.Rprofile. -
micromambaandRETICULATE_CONDA: reticulate activates a conda environment again before using its Python, with a conda program, which a Pixi project doesn’t have (rstudio/reticulate#1650). conda-forge’s micromamba does that. -
libpython, for Python 3.15 or later: conda-forge keeps Python’s shared library, which reticulate loads, in a package of its own. - On Windows, the settings are written differently, as Pixi doesn’t expand
$CONDA_PREFIXthere. They’re only written if the project haswin-64; if you add it later, runuse_pixi_python()again.
Things to know
-
reticulate::py_require()doesn’t install into the project’s Python: add Python packages withpixi_add()instead. - PyPI packages are for what conda-forge doesn’t have: a package from conda-forge can bring the system libraries it needs, one from PyPI can’t. They need Python in the environment, and Pixi installs them with uv, next to the conda packages.