R Package Management

This page explains how R packages should be installed and managed on the shared workstation.

The workstation uses shared R installations through conda environments, for example:

conda activate R-4.4

The recommended approach is:

use shared conda environments for the base R version and common system-level packages
use project-level renv for reproducible R projects
avoid installing many personal packages directly into the shared R environment
ask the administrator before installing system-level Linux packages

1 Why package management matters

Different projects may need different versions of R packages.

For example, one project may require an older version of brms, while another project may need the newest version of tidyverse.

If everyone installs packages into the same shared R library, one user’s package update may break another user’s project.

2 Recommended policy

Scenario	Recommended approach
Quick test or small script	Use the shared R conda environment
Personal analysis	Use your personal R library or `renv`
Project with collaborators	Use `renv`
Manuscript or reproducible analysis	Use `renv`
Package needs Linux system libraries	Ask the administrator
Software should be available to all users	Ask the administrator to install it in the shared conda environment

3 Check which R you are using

After activating an environment:

conda activate R-4.4
which R
R --version

Inside R:

R.home()
.libPaths()

.libPaths() shows where R will look for packages.

4 Personal R package library

If you install packages without administrator permission, R may install them into your personal library.

This is usually inside your home directory, for example:

/home/username/R/x86_64-conda-linux-gnu-library/4.4

This is acceptable for personal work, but it is not ideal for shared projects because other users may not have the same packages.

5 Installing R packages for personal use

Activate the R environment:

conda activate R-4.4
R

Then in R:

install.packages("tidyverse")

Check where the package was installed:

find.package("tidyverse")

6 Using renv for a project

renv creates a project-specific R package library and records package versions in a lockfile.

This is the recommended approach for collaborative and reproducible projects.

6.1 Step 1: Go to your project folder

cd /data/projects/my-project
conda activate R-4.4
R

6.2 Step 2: Initialise renv

Inside R:

install.packages("renv")
renv::init()

This creates project files such as:

renv/
renv.lock
.Rprofile

6.3 Step 3: Install packages inside the project

install.packages("tidyverse")
install.packages("cmdstanr")

6.4 Step 4: Save the package versions

renv::snapshot()

This updates:

renv.lock

The renv.lock file should be committed to Git.

6.5 Step 5: Restore the project on another account or machine

When another user opens the same project, they can run:

renv::restore()

This installs the package versions recorded in renv.lock.

7 What should be committed to Git?

Commit these files:

renv.lock
.Rprofile
renv/settings.json

Do not commit the full package library:

renv/library/

The package library can be recreated using:

renv::restore()

8 Recommended project structure with renv

project-name/
├── data/
├── scripts/
├── results/
├── renv/
├── renv.lock
├── .Rprofile
└── README.md

9 When not to use renv

You may not need renv for:

very small one-off scripts
teaching examples
quick checks
temporary exploratory work

For anything that may become a paper, report, Shiny app, or shared analysis, use renv.

10 Installing packages into the shared conda R environment

Only administrators should install packages into the shared R conda environment.

Example administrator workflow:

conda activate R-4.4
mamba install -c conda-forge r-tidyverse r-data.table r-cmdstanr

This is useful for common packages needed by many users.

However, not every R package needs to be installed globally.

11 R packages from CRAN vs conda-forge

There are two common ways to install R packages:

11.1 From inside R

install.packages("package_name")

11.2 From conda-forge

mamba install -c conda-forge r-package_name

For shared environments, conda-forge packages are often easier to manage at the system level.

For project-specific work, renv is usually better.

12 Packages requiring Linux system libraries

Some R packages need Linux system libraries before they can be installed.

Examples include packages that depend on:

XML
SSL
curl
GDAL
GEOS
PROJ
Java

If installation fails with missing system libraries, ask the administrator.

Do not repeatedly try random fixes in the shared environment.

13 Snap packages

Snap packages are mainly useful for standalone applications, especially desktop apps or command-line tools packaged as snaps.

Snap is not recommended for managing R packages.

Use this rule:

Need	Use
R package	`renv`, CRAN, or conda-forge
Python package	conda, mamba, pip, or project environment
System package	`apt`, administrator-managed
Standalone application packaged as snap	`snap`, administrator-managed

14 Check installed snap packages

snap list

15 Install a snap package

Only administrators should install snap packages system-wide.

Example:

sudo snap install package-name

Some snap packages require classic confinement:

sudo snap install package-name --classic

16 Summary

For most R users:

conda activate R-4.4
cd /data/projects/my-project
R

Then inside R:

install.packages("renv")
renv::init()
install.packages("tidyverse")
renv::snapshot()

For collaborators:

renv::restore()