R users have access to thousands of community contributed packages. Most users rely on dozens if not hundreds of packages. Organizing these packages can take a fair amount of administrative effort, especially when multiple versions of R exist across multiple servers. This document lays out a simple strategy for managing packages for a team of analysts on a server.
R packages are installed into libraries, which are directories in the file system containing a subdirectory for each package installed there. These libraries can be common libraries or user libraries. Common libraries are managed by administrators. User libraries are managed by individual users. Administrators can set up multiple libraries and can use any combination of both common and user libraries.
You can see all the library paths installed for your user by issuing the .libPaths() command in the R terminal. If you have multiple libraries installed, packages will be loaded in the order specified by .libPaths().
The R installation and administration guide has detailed information on managing libraries.
There are three general strategies for managing libraries:
- Install all packages in user libraries. This strategy is the easiest to set up and administer, as it puts full responsibility on the analyst for package management. However, this strategy also duplicates commonly used packages.
- Install all packages in common libraries. This strategy forces the administrator to manage all packages. It prevents the users from downloading their own packages, and it may slow down the installation process.
- Install some packages in common libraries and some in user libraries. This strategy allows frequently used packages to be installed in common libraries while still giving users the ability to install user specific packages.
All three strategies can be useful, but for most situations, we recommend the third. By default, R is configured for both common and user libraries. We often see organizations install frequently used packages in a common library while allowing users to install specific packages in their user library.
User specific libraries
There are many advantages to having a user library. Users might want a different version of a package than is installed in the common library. It is typically more convenient for users to install new libraries into their home directory than it is to put in a request to have one installed in a shared library. Users often have a lot of packages that are specific to their needs and not shared by other users. It is also a natural place to build, test, and install custom packages.
User specific libraries are typically created in the home directory mounted from a shared filesystem. Installing to the home directory allows users to reference their libraries across multiple servers. You can change the location for the user library by setting the r-libs-user in /etc/rstudio/rsession.conf. The user library is set up by default.
There are also advantages to a common library. It reduces overall tasks and redundancies, and ensures that groups of users all reference the same commonly used libraries. There are two types of common libraries.
The first common library is the R library associated with the R installation. R comes with a single library, R_HOME/library, which contains the standard and recommended packages. Any package installed here will also be available to all users on that server; however, administrators will need root privileges to complete the install. Some administrators will have a list of packages that are installed into this directory at the time R is installed.
The second common library is the site library. The site library is not set up by default, but can be configured in R_HOME/etc/Rprofile.site. The site library can be a local library or mounted from a shared filesystem (e.g. alongside the home directories). If the site library is installed on a shared filesystem, it can be accessible to multiple servers which may reduce administration overhead. If desired, the site library can be managed by a user without root privileges on behalf of all users. However, it is inadvisable to give all users write access, as each install will overwrite existing package versions.
RStudio Workbench / RStudio Server Pro Features
R libraries are associated with a specific version of R. When you upgrade R, you typically need to upgrade your packages.
By default, user libraries are associated with the major and minor release of R, but not the point release. For example, versions 3.1.0 and 3.2.0 will use different libraries, whereas versions 3.2.1 and 3.2.2 will share the same library. In RStudio Workbench (previously RStudio Server Pro) you can set r-libs-user=~/R/library in /etc/rstudio/rsession.conf so that users reference a single location for all versions of R.
If you manage packages centrally with a site library you may want to configure the user-interface of the RStudio IDE to discourage end-user package installation. In RStudio Workbench use allow-package-installation=0 in /etc/rstudio/rsession.conf.