An environment has its own R
A Pixi environment is a folder, .pixi/envs/default/ in your project. It holds everything the project needs: R itself, the R packages, and the system libraries those packages use, such as GDAL or libxml2. They all come from conda-forge and are built to work together.
So a Pixi project doesn’t use the R you normally use. It uses the R in its environment, with that R’s package library. Different projects can use different versions of R, side by side.
Start R through Pixi
pixi run R starts the environment’s R. Before it does, Pixi activates the environment: it sets up environment variables that some packages need, such as where GDAL finds its data.
Activating takes a few seconds in an environment with R, mostly because conda-forge’s R reconfigures Java each time. So use_pixi() turns on Pixi’s activation cache for the project, in .pixi/config.toml: Pixi reuses the activation until the project changes, and R starts in a fraction of a second. The cache is experimental in Pixi. To turn it on in a project set up another way:
use_pixi(activation_cache = FALSE) leaves it off. The setting it writes is Pixi’s experimental.use-environment-activation-cache.
IDEs need to be pointed at the environment’s R; see Using rpix with an IDE.
When an IDE starts R directly
Positron and VS Code start the environment’s R themselves, without Pixi, so the environment isn’t activated. use_pixi() adds a few lines to the project’s .Rprofile that make up for that. When R starts, they:
- Remove your personal library from
.libPaths()(see below), before any package loads. - Call
rpix::pixi_activate(), which sets the environment variables Pixi would have set, and adds the project’s own library. If the environment’s R doesn’t have rpix, e.g. for a collaborator, they say so, with the command that installs it.
In R that isn’t from the project’s environment, pixi_activate() changes nothing, and tells you how to start the right R instead.
Positron activates the environment itself when it starts an R it found in a Pixi environment. On Windows, the environment’s R can’t start at all without activation, so start VS Code through Pixi there; see Using rpix with an IDE.
Why rpix doesn’t change .libPaths()
You can’t safely point an R you already have running at a Pixi environment’s library. Packages with compiled code are built for one particular R and set of system libraries. Loaded into a different R, they can crash it, often only when you load the package.
Earlier versions of rpix did this, from the .Rprofile. use_pixi() removes that setup from projects that still have it.
Keep your personal library out
conda-forge’s R also looks in your personal package library, and even looks there first. That’s the one your usual R installs into, such as ~/Library/R/x86_64/4.5/library on macOS, or %LOCALAPPDATA%/R/win-library/4.5 on Windows. So packages built for your usual R can be loaded into the environment’s R. This is a long-standing issue in conda-forge’s R.
use_pixi() adds conda-forge’s conda-ecosystem-user-package-isolation to the project, which fixes this. When Pixi activates the environment, it points R_LIBS_USER at a folder that doesn’t exist, so R leaves the personal library out. It does the same for Python’s user packages. To add it to a project yourself:
rpix::pixi_add("conda::conda-ecosystem-user-package-isolation")Pixi applies this when it starts R, as pixi run R does, and the project’s .Rprofile takes care of it when an IDE starts R directly. Check with:
What rpix runs
Each rpix function runs a Pixi command, and shows it:
rpix::pixi_add("dplyr")
#> ℹ Running `pixi add r-dplyr --manifest-path pixi.toml`So you can always do the same in a terminal, and learn Pixi along the way. With dry_run = TRUE, rpix shows the command without running it.
rpix finds the project from the working directory, looking upwards for a pixi.toml. In R started by Pixi, it uses that R’s project instead.