Our first attempt at solving the problem of reproducible environmentswaspackrat. While welearned a lot from packrat, it ultimately proved challenging to use inways that were difficult to fix. This led us to create renv, a systemwith fewer surprises and better defaults. If you’re an existing packratuser, you can callrenv::migrate() to switch renv, thenread on to learn about the main differences:
The renv lockfilerenv.lock is formatted asJSON. This should make the lockfileeasier to use and consume with other tools.
renv no longer attempts to explicitly download and track Rpackage source tarballs within your project. This was a frustratingdefault that operated under the assumption that you might later want tobe able to restore a project’s private library without access to a CRANrepository. In practice, this is almost never the case, and the timespent downloading + storing the package sources seemed to outweigh thepotential reproducibility benefits.
Packrat tried to maintain the distinction between so-calledstale packages; that is, R packages which were installed byPackrat but were not recorded in the lockfile for some reason. Thisdistinction was (1) overall not useful, and (2) confusing. renv nolonger makes this distinction:snapshot() saves the stateof your project library torenv.lock,restore() loads the state of your project library fromrenv.lock, and that’s all.
In renv, the global package cache is enabled by default. Thisshould reduce overall disk-space usage as packages can effectively beshared across each project using renv.
renv’s dependency discovery machinery is more configurable. Thefunctionrenv::dependencies() is exported, and users cancreate.renvignore files to instruct renv to ignorespecific files and folders in their projects. (See?renv::dependencies for more information.)