New guidance on using system R and R libraries

New R version updates

I’ve written on the topic of R libraries before:

With the latest update to R-4.3.1, we’ve had to change the install location and type, so we felt that an update post was in order.

Let’s cover how to activate these new installs and how we are suggesting folks manage their R libraries going forward.

New install locations

New R installations will be managed using micromamba, which is a sort of extension and alternative implementation of a subset of conda commands and conda channels. Installs will be subdirectories here:


Activating the R install

You will identify the R version you wish to activate, e.g. 4.3.1 and determine if an install is made for this version:

$ ls /local/cluster/micromamba/envs/R-4.3.1
   conda-meta   fonts     libexec   scripts   var
 bin           doc          include   man       share     x86_64-conda-linux-gnu
 cmake         etc          lib       sbin      ssl       x86_64-conda_cos6-linux-gnu

If the version is not installed, please submit a support request

To activate R-4.3.1 temporarily, you can check out a node with qrsh and run:

source /local/cluster/micromamba/envs/R-4.3.1/

Then, you can just run R and give it a trial to see if you are satisfied with the new version. To make the changes permanent across logins, you’ll need to modify your $PATH environment variable in your ~/.bashrc or ~/.cshrc e.g.

echo 'export PATH=/local/cluster/micromamba/envs/R-4.3.1/scripts:${PATH}' >> ~/.bashrc
echo 'setenv PATH /local/cluster/micromamba/envs/R-4.3.1/scripts:${PATH}' >> ~/.cshrc

Then, when you log in next time, you’ll have access to R and Rscript for that R version.

Managing R libraries

One difficulty with managing R libraries across different R installs is that sometimes a R library installed for the system will be incompatible with R libraries installed in a conda environment. In the past, I’ve suggested a method to install R libraries in a particular directory and set the R_LIBS variable to point to that R library directory, and unset R_LIBS_USER.

At the time, this information and plan made sense because managing R installs was easier and R could be compiled using CentOS system gcc and other standard system libraries. Now, using the system gcc to compile R and libraries is not possible because it is too out-of-date.

At this time, we are going to use a multi-tiered approach to managing R libraries:

  1. Some R libraries will be managed with conda because the CentOS 7 binaries and c/c++ libraries are incompatible.
    • These R libraries will be found in e.g. /local/cluster/micromamba/envs/R-4.3.1/lib/R/library
  2. Some R libraries are commonly used and will be installed in the site libraries directory. This allows CQLS employees easy access to install packages for folks and to help troubleshoot issues.
    • These R libraries will be found in e.g. /local/cluster/R/x86_64-conda-linux-gnu-library/4.3
  3. Some R libraries will be required by some users and will be managed by users pointing R to their own user-managed directories using either $R_LIBS or $R_LIBS_USER.
    • These R libraries will be found in e.g. /nfs/dept/lab/home/user/opt/R/...

The conda libraries and R site libraries should be accessible to you with no additional actions of your own. To set up your user-managed R libraries, we suggest a novel (to us) method based on the R documentation.

The novelty is that you do not need to specify a single directory to house your R libs, but take advantage of some variable expansion that is built in to how R parses the $R_LIBS_SITE and $R_LIBS_USER environment variables. As an example, we set R_LIBS_SITE='/local/cluster/R/%p-library/%v' for you, and R will be able to identify a major.minor version specific R library folder based on if the R was installed using conda or the system.

Users can take advantage of this as well.

As an example, I set my R library environment variables like this:

unset R_LIBS
export PATH=/local/cluster/micromamba/envs/R-4.3.1/scripts:${PATH}
export R_LIBS_USER='/nfs4/core/home/davised/opt/R/%p-library/%v'

The caveat to using this approach is that directories that are not generated prior to starting R will not be used for R library installs. To determine if a directory is present and being used:

$ Rscript -e '.libPaths()'
[1] "/nfs4/core/home/davised/opt/R/x86_64-conda-linux-gnu-library/4.3"
[2] "/local/cluster/R/x86_64-conda-linux-gnu-library/4.3"
[3] "/local/cluster/micromamba/envs/R-4.3.1/lib/R/library"

If you do not see your own user directory, but only the conda libraries and site libraries, then you can see where R is expecting to find a directory, and then generate that directory like this:

$ Rscript -e 'Sys.getenv("R_LIBS_USER")'
[1] "/nfs4/core/home/davised/opt/R/x86_64-conda-linux-gnu-library/4.3"
$ mkdir -p /nfs4/core/home/davised/opt/R/x86_64-conda-linux-gnu-library/4.3

Common issues

If you cannot install new R libraries, ensure the directory that R is expecting to find exists, as above. If you are certain that part is correct, send a support ticket with the R library, R version, and R install location.

If you are having issues with incompatible R libraries, make sure you have unset your $R_LIBS or $R_LIBS_USER as appropriate and/or they are not pointing to a directory with libraries from a different R version.

If you cannot update a particular R library that you really need updated because, e.g. the library is installed in the conda env libraries or site libraries, send a support ticket with the R library, R version, and R install location.