Video Notes

By default, R installs packages into a global system library shared across projects. This can create problems when newly updated packages conflict with old code, or when collaborators might have different package versions installed on their machines.

{renv} isolates dependencies per project so each project controls its own environment.

This ensures your projects are portable and reproducible.

Getting Started

1. Install {renv} (once globally)

install.packages("renv")

2. Initialize {renv} in a project

Open your project directory and run:

renv::init()

This will create 3 things:

1. The project library, renv/library: contains all of the packages currently used by your project. This is the core idea behind {renv}: instead of relying on one global library shared across every project, {renv} creates a separate library for each project. This isolation allows different projects to use different package versions, and it ensures that installing, updating, or removing a package in one project won’t affect any others.

2. The lockfile, renv.lock: stores detailed information about each package and its version so the environment can be recreated on another machine.

3. The .Rprofile file: runs automatically whenever you start R within the project, and {renv} uses it to configure your session to use the project’s private library. Once {renv} is enabled for a project, it remains active every time you open it (unless you explicitly turn it off).

Installing and Snapshotting

After initialization, install packages as you normally would. E.g.:

install.packages("dplyr")
install.packages("ggplot2")

Then record the environment:

renv::snapshot()

This updates renv.lock with the current package state.

renv::install("dplyr@1.1.4")
renv::snapshot()

Restoring the Environment

On a new machine:

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

restore() reads renv.lock and installs the correct versions of your project’s packages.

Confirmation

The command .libpaths can be used to see what paths packages will be located in.

If you run .libpaths in a renv managed project you should see it points to you project library and the renv cache folder:

> .libPaths()
[1] "/Users/Susan/Desktop/renv-demo/renv/library/macos/R-4.5/aarch64-apple-darwin20"                        
[2] "/Users/Susan/Library/Caches/org.R-project.R/R/renv/sandbox/macos/R-4.5/aarch64-apple-darwin20/4cd76b74"

If you run the command in a non-renv-managed project, you’ll see the system path is used:

> .libPaths()
[1] "/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library"

What Gets Tracked in Git

When renv is initiated in a project, it generates a file at renv/.gitignore with the appropriate settings for which paths should be excluded from your repository:

library/
local/
cellar/
lock/
python/
sandbox/
staging/

These paths are managed by {renv} and built when renv::restore() is invoked.

New files generated by renv that you will track in your repository include:

• .Rprofile
• renv.lock
• renv/.gitignore
• renv/activate.R
• renv/settings.R