Global library present despite Pixi R interpreter

[roaldarbol]

System details:

Positron and OS details:

Positron Version: 2026.01.0 build 85
Code - OSS Version: 1.106.0
Commit: bbe2c76
Date: 2025-12-12T07:22:08.514Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin x64 24.6.0

Session details:

R 4.5.2

Describe the issue:

Now that there is experimental support for Pixi R interpreter discovery (#3724, amazing that this is done!), I would expect only to be able to use packages installed with Pixi, however I can still access global libraries which defeats the reproducibility gains of using Pixi with a separate R installation.

Steps to reproduce the issue:

1. Install latest build of Positron
2. Enable Pixi R interpreter discovery
3. Start project that has a pixi.toml file
4. Install R with pixi add r-base
5. Open Positron and choose the Pixi R interpreter
6. See .libPaths()

> .libPaths()
[1] "/Users/roaldarbol/Library/R/x86_64/4.5/library"                                      
[2] "/Users/roaldarbol/Projects/Papers/Belay-Paper/.pixi/envs/default/lib/R/library"

For example, in the above, I have only installed r-base from conda-forge, but am still able to load dplyr:

> library(dplyr)

Attaching package: ‘dplyr’

The following objects are masked from ‘package:stats’:

    filter, lag

The following objects are masked from ‘package:base’:

    intersect, setdiff, setequal, union

Expected or desired behavior:

I would expect to only have access to the Pixi libraries.

Other

I understand that this is not just as easy as this; what would we for example expect from install.packages in such a case? Just to add the packages to the Pixi libpath, but without adding them to pixi.toml. I started a while back making the rpix package that installs packages with Pixi from the R console (it basically relays messages with system()). Maybe that would be worth co-opting to mask install.packages? Would be more than happy to assist where possible.

[jmcphers]

As far as I can tell, this global library is not added by Positron. It is also present if you just run Pixi R in a plain terminal.

% pixi run r

R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
Copyright (C) 2025 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20.0.0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> .libPaths()
[1] "/Users/jmcphers/Library/R/arm64/4.5/library"
[2] "/Users/jmcphers/data/pixi-r-example/.pixi/envs/default/lib/R/library"

Is this behavior something that should be changed upstream in Pixi?

[roaldarbol]

You're right, I get the same thing actually. I wonder where the right place might be for this, whether it's simply a base R thing. When I simply start R with my Rig installation, I get the same order:

❯ which r
╭───┬─────────┬──────────────────┬──────────╮
│ # │ command │       path       │   type   │
├───┼─────────┼──────────────────┼──────────┤
│ 0 │ r       │ /usr/local/bin/r │ external │
╰───┴─────────┴──────────────────┴──────────╯

Projects/tests/test-pixi-r via 🧚 v0.61.0
❯ r --version
R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
Copyright (C) 2025 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin20

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.


Projects/tests/test-pixi-r via 🧚 v0.61.0
❯ r

R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
Copyright (C) 2025 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin20

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> .libPaths()
[1] "/Users/roaldarbol/Library/R/x86_64/4.5/library"
[2] "/Library/Frameworks/R.framework/Versions/4.5-x86_64/Resources/library"

How do you deal with this with renv? In rpix, I also made functions to handle library paths, as have I previously done in a Pixi R template repository, see here.

[jdblischak]

@roaldarbol you might be interested in conda-ecosystem-user-package-isolation. It helps (it disables R_LIBS_USER), but it's not perfect. Many years ago I tried to convince the conda-forge folks to fully isolate their r-base conda binary, but was ultimately unsuccessful (conda-forge/r-base-feedstock#65).

[roaldarbol]

Well, that was not on my potential issues bingo-card... it seems so backwards that it does this - and to be fair, it seems there was only a single person pushing back really, so I wonder if we could resurrect the PR (from 2018, that's crazy!)? Maybe with a bit of Posit and Prefix backing, it might finally make it through? Otherwise, could we simply make a r-base-isolated feedstock? I feel like this shouldn't be handled by either Pixi or Positron (at least if we can help it), as I would expect to get the same behaviour everywhere. If it were to do so, I guess Positron could unset R_LIBS_USER when a conda/pixi R interpreter is chosen?

(I also just saw your PR was mentioned on an earlier Pixi issue I made a while back (prefix-dev/pixi#587)).

Personally, like you @jdblischak (I think), I'd expect it to "just work", so having to install an extra package simply to shield the environment seems very off to me. Not good UX.

@wolfv Just FYI, as I know you're just as keen as I to get proper Pixi R support - in Positron and elsewhere.

@jmcphers So this is not a Positron issue, but an issue affecting Positron. I guess you could convert this into a discussion, or keep the issue open so users who face this issue may find it (and the proposed patches) until a proper solution is found.

[jmcphers]

I'm going to close this since there's no change I think we should make on the Positron side, and convert it to a discussion as you suggest.