renv — A Private Library per Project
Last spring your harvest analysis ran perfectly. This autumn you updated your packages for another project, and now the old script throws errors, or worse, gives slightly different numbers. A new volunteer tries it on their laptop and hits a third set of problems. All of these have the same cause: every project was sharing one library of whatever versions happened to be installed.
The rule
renv freezes a project's package versions: snapshot to save, restore to rebuild.
renv is a package (install it once with install.packages("renv")) that gives each project its own private library plus a record of exactly which versions it uses. Three verbs cover everyday work:
renv::init() # once: set up a private library for this project
renv::snapshot() # after installing or updating: record the versions
renv::restore() # on any machine: install exactly the recorded versionsrenv::init() creates a few things in the project folder:
renv.lock: the lockfile, a small JSON file listing every package the project uses, with its exact version and where it came from..Rprofile: a start-up file that switches renv on whenever R opens this project.renv/: holdsactivate.Rand the privatelibrary/folder.
An entry in the lockfile looks like this:
"dplyr": {
"Package": "dplyr",
"Version": "1.1.4",
"Source": "Repository",
"Repository": "CRAN"
}Inside the project, install packages as usual. They go into the private library, so updating a package here cannot break another project, and updates elsewhere cannot break this one. renv::status() tells you when the library and the lockfile disagree, for example after you install something new but forget to snapshot.
For version control, commit renv.lock, .Rprofile and renv/activate.R. Do not commit renv/library/: it is large and specific to one machine, and renv's own .gitignore already leaves it out.
The shortcut
Think of renv.lock as a recipe card. snapshot() writes the card from what is in your kitchen right now; restore() cooks the same dish in someone else's kitchen from the card. So: init once, snapshot after every change, restore on arrival.
You: set up
In the project folder, run
renv::init(). The project now has its own library and a lockfile.
The classic slip is installing a package and forgetting to snapshot. Your code works, but the lockfile does not mention the package, so the volunteer's restore leaves it out. renv::status() catches this.
Drills
Answer fast — trust the rule.
Which file records the exact package versions of an renv project?
You installed a new package in an renv project and used it in a script. What do you run so teammates get it too?
A teammate has just cloned the project. Which command installs the recorded versions?
Which of these should NOT be committed to version control?
Why does renv give every project its own library?
Remember
- renv freezes a project's package versions: snapshot to save, restore to rebuild.
- Shortcut: the lockfile is a recipe card. Init once, snapshot after changes, restore on arrival.
- Trap: installing without snapshotting, and committing
renv/library/.