.libPaths() after activation of a rv environment shows global library path.

[gwangjinkim]

I am in a MacOS M3Max pro.

After installation of rv and generation of an environment

rv init test-rv
cd test-rv

rv activate
rv add tidyverse

R

I see:

.libPaths()
[1] "/Users/me/projects/R/test-rv/rv/library/4.4/arm64"                               <= projects' local library folder
[2] "/opt/homebrew/Caskroom/miniconda/base/envs/R443/lib/R/library"  <= global R's library folder

That means this repository uses primarily the rv environments' locally installed packages.
But if a package is not there but peresent int he global library folder which belongs to the global R outside of the rv environment,
a package would be recognized and imported from there.

Why is this bad? It means the session "sees" packages which are NOT recorded in the .lock file.
This violates the reproducibility of a project/session because packages other than in the current .lock file listed
can potentially be loaded.

I tried to get solely the rv environment's R packages in the project, one has to do at the beginning of the session:

.libPaths(.libPaths()[2], include.site=FALSE)

But this did not get rid of the global library path.

.libPath

function (new, include.site = TRUE) 
{
    if (!missing(new)) {
        new <- Sys.glob(path.expand(new))
        paths <- c(new, if (include.site) .Library.site, .Library)   # <- This line adds at the end of the paths vector `.Library`, the global library path.
        paths <- paths[dir.exists(paths)]
        .lib.loc <<- unique(normalizePath(paths, "/"))   # it somehow access it using a closure
    }
    else .lib.loc
}
<bytecode: 0x1503730c0>
<environment: 0x150374390>

Since .lib.loc is acceessed as a closure <<-, it seems to be we can't access it and delete .Library.

Is this desired that the global .Library path stays in .libPaths() ?
Shouldn't the environment have only the environment library accessible during the session?

[dpastoor]

Hi, this ibe because of how that miniconda library is being expose. Are you using the r distribution from miniconda? Somewhere, the actual environment variable R_LIBS or R_LIBS_SITE are being set to point to that miniconda path, which, is what .Library.site picks up on.

Your solution will be one of two things:

1. in your .Rprofile after sourcing the rvr activate script that gets dropped, add your own additional logic to detect then call that .libPaths() that is present.

something like the following pseudocode

source("rv/scripts/activate.R")
if (length(.libPaths()) == 2 && grepl(.libPaths()[1], "Caskroom") {
.libPaths(.libPaths()[2], include.site=FALSE)
}

2. switch to a different R installation that doesn't so aggressively adjust your environment - eg using rig to install R

[gwangjinkim]

Thank you a lot @dpastoor !!
Yes, I use it from Miniconda.

I thought, too, that

source("rv/scripts/activate.R")
if (length(.libPaths()) == 2 && grepl(.libPaths()[1], "Caskroom")) {
.libPaths(.libPaths()[2], include.site=FALSE)
}

would work - but strangely after this, I still keep both in .libPaths().
Never seen such aggressive behavior.
This is however - as I wrote above - because the .libPaths definition adds .Library again at the end of the file.

So only option 2 stays then for me.

[gwangjinkim]

No, this is not a conda issue I realize.

I deactivate conda globally:

conda deactivate

The (base) at the beginning of the command line disappeared as expected.

And used my global R:

R

In my test-rv folder, I started the R session and see at the start again:

library paths: 
  /Users/myname/projects/R/test-rv/rv/library/4.4/arm64
  /Users/myname/Library/Caches/org.R-project.R/R/renv/sandbox/macos/R-4.4/aarch64-apple-darwin20/f7156815

Trying to delete the second library path again deleted only the rv library path:

> .libPaths()
[1] "/Users/myname/projects/R/test-rv/rv/library/4.4/arm64"                                                  
[2] "/Users/myname/Library/Caches/org.R-project.R/R/renv/sandbox/macos/R-4.4/aarch64-apple-darwin20/f7156815"
> .libPaths(.libPaths()[2], include.site=F)
> .libPaths()
[1] "/Users/myname/Library/Caches/org.R-project.R/R/renv/sandbox/macos/R-4.4/aarch64-apple-darwin20/f7156815"

I will try the same in my Linux machine.

I played through the same game in my Linux machine (ubuntu).
The same problem!

.Library contains the global library path and this is NOT destroyable.

Asking to reopen this issue - since this is something

• this problem goes deeper than I thought. It affects any R installed (be it with conda, rig, just global R, ...)
• the .Library variable creates the "problem".
• the .lib.loc variable can't be accessed, because it is generated as a closure variable when R base generates the function .libPaths.
  => with the consequence that rv can't generate an environment where the local rv library is the single source for packages.
  This affects the reproducibility of the environment (the .lock file is not the sole source for package for the session - packages from the global library path can contaminate the session.

[gwangjinkim]

This is addressed and now resolved by PR: #402

The solution is to follow how the tidyverse team solved this problem in their renv package:
They generated a sandbox library (here under rv/sandbox) and pointed .Library to this library folder.
By ensuring that only "base" and "recommended" packages are copied into the sandbox, they can assure that no user-added random package is in .Library. Thus, in endeffect, despite .libPaths() points to two places - the rv library folder and the sandbox folder, effectively, we deal with a clean rv library folder without contaminations.

Setting the environment variable RV_SANDBOX=0 will escape this mechanism and restore the old behavior.

[gwangjinkim]

No need to reopen this issue again. I formulated the problem clearer in #403 .