Custom definition of R_LIBS

[michaelmayer2]

Container image name

rocker/r-ver:4.4.0

Container image digest

sha256:73adabf378930f8744f56bac1fe5e99870532eb4ced1a15075991bac909d21f3

What operating system related to this question?

Linux

System information

• Docker Version 27.1.1

Question

I am curious why you added

rocker-versioned2/scripts/install_R_source.sh

Line 149 in 92e20d2

echo "R_LIBS=\${R_LIBS-'${R_HOME}/site-library:${R_HOME}/library'}" >>"${R_HOME}/etc/Renviron.site"

to Renviron.site. According to the R documentation, the presence of site-library in ${R_HOME}/site-library alone will add this to libPaths() (cf. https://stat.ethz.ch/R-manual/R-devel/library/base/html/libPaths.html "First, .Library.site is initialized from R_LIBS_SITE. If this is unset or empty, the ‘site-library’ subdirectory of R_HOME is used. Only directories which exist at the time of initialization are retained. Then, .libPaths() is called...").

I have recently seen a case where the current definition of R_LIBS in Renviron.site in the docker image leads to the behaviour of .libPaths() listing the folders in reverse order (i.e. R_LIBS_USER the last) which makes package installations using install.packages() impossible (unless you really set target .libPaths() manually.

I am sure there is valid reason for your approach to Renviron.site - just curious to understand the history of it.

[michaelmayer2]

Steps to reproduce:

docker run -ti rocker/r-ver:4.4.0 bash

In container, run

useradd -s /bin/bash -m mm 
su - mm
R

In R console, run

install.packages("SuppDists")
.libPaths()

.libPaths() will report

> .libPaths()
[1] "/usr/local/lib/R/site-library"             
[2] "/usr/local/lib/R/library"                  
[3] "/home/mm/R/x86_64-pc-linux-gnu-library/4.4"

After removing Renviron.site and rerunning a new R session, libPaths() will report

> .libPaths()
[1] "/home/mm/R/x86_64-pc-linux-gnu-library/4.4"
[2] "/usr/local/lib/R/site-library"             
[3] "/usr/local/lib/R/library"  

as expected.

[eitsupi]

@cboettig Any idea?

[cboettig]

Right, so this follows conventions I think Dirk originally established with debian's r-base (Note @eddelbuettel is both rocker maintainer and a debian mantainer), and he can probably explain better.

Note the permissions -- the default user is added to staff group, which is granted write permissions to site-library. I believe the motivation was mostly about space, the user could then upgrade packages in the site library rather than having multiple copies, and in a multi-user environment you didn't end up with each user needing a their own copy of site-library.

Of course users are free to override the R_LIBS env to whatever they want, e.g. in ~/.Renviron.

In containerized setups these days it's also still a common pattern that even user-permission installs go in a system path 'below' home (the Jupyter project uses /srv or /opt). It's also common to mount the user's home with a bind mount that would overwrite the container home directory, so this ensures that packages even if installed by non-root user aren't lost.

[eddelbuettel]

As I read it the issue here seems to be the reordered path, ie why

> .libPaths()
[1] "/usr/local/lib/R/site-library"             
[2] "/usr/local/lib/R/library"                  
[3] "/home/mm/R/x86_64-pc-linux-gnu-library/4.4"

per #857 (comment) by @michaelmayer2 above.

We usually put the user PATH first:

edd@rob:~/git$ docker run --rm -ti rocker/r-base bash
root@57eb7eafca96:/# useradd -s /bin/bash -m dirk
root@57eb7eafca96:/# su - dirk
dirk@57eb7eafca96:~$ Rscript -e '.libPaths()'
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"      
[3] "/usr/lib/R/library"           
dirk@57eb7eafca96:~$ mkdir -p R/x86_64-pc-linux-gnu-library/4.4
dirk@57eb7eafca96:~$ Rscript -e '.libPaths()'
[1] "/home/dirk/R/x86_64-pc-linux-gnu-library/4.4"
[2] "/usr/local/lib/R/site-library"               
[3] "/usr/lib/R/site-library"                     
[4] "/usr/lib/R/library"                          
dirk@57eb7eafca96:~$ 

[michaelmayer2]

Thanks @eddelbuettel for your input - So we seem to have a different behaviour when comparing r-ver and r-base containers. For me the behaviour of r-base makes more sense to me and is more appropriate for our use case of running Singularity/Apptainer containers with the R installation baked in and users being able to add packages into R_LIBS_USER as they please.

docker run -ti rocker/r-ver:4.4.0 bash
root@2d5be3fe7143:/# useradd -s /bin/bash -m dirk
root@2d5be3fe7143:/# su - dirk
dirk@2d5be3fe7143:~$ Rscript -e '.libPaths()'
$[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     
dirk@2d5be3fe7143:~$ mkdir -p R/x86_64-pc-linux-gnu-library/4.4
dirk@2d5be3fe7143:~$ Rscript -e '.libPaths()'
[1] "/usr/local/lib/R/site-library"               
[2] "/usr/local/lib/R/library"                    
[3] "/home/dirk/R/x86_64-pc-linux-gnu-library/4.4"

[eitsupi]

Thank you. Is anyone interested in a fix for this?
(I do not intend to do the work as I am not in trouble)

[cboettig]

@michaelmayer2 would you be interested in making a PR for this? matching the r-base behavior makes sense and I think was what was intended here.

[michaelmayer2]

@cboettig PR #866 is there for your review.