Using renv: where should renv itself be installed?

Question

I am getting started with collaborating with team members on R projects using renv. While I can (mostly) get it to work, I am a bit confused about whether and where to install renv itself. According to the documented workflow I basically need renv installed before I start a new project with renv.

However, when I do not have renv installed, and clone a repo that uses renv, it seems to install (bootstrap?) itself. But it does this within the local renv environment.

I have a couple of questions regarding this:

• Do you recommend to have renv installed "outside" the renv virtual environment?
• How do you deal with differences in versions of renv itself between what is e.g. installed on my machine and present in a repo that I clone, and which renv I would like to replicate? I ran into problems with this one, could not replicate a renv from a cloned repo with a different renv version.
• On a more conceptual level: why is renv itself part of the virtual environment it creates? That's not the case for the python virtual environment managers I know.

Answer 1

Do you recommend to have renv installed "outside" the renv virtual environment?

We do. In fact, this is necessary if you want to initialize an renv project in the first place, since this is done by calling renv::init() -- and so the regular renv initialization workflow expects renv to be installed into the user library.

How do you deal with differences in versions of renv itself between what is e.g. installed on my machine and present in a repo that I clone, and which renv I would like to replicate? I ran into problems with this one, could not replicate a renv from a cloned repo with a different renv version.

Since renv is just an R package, you can install or upgrade (or downgrade) the version of renv used within a project as required, without affecting other projects. For example, installing the latest version from CRAN can be done with a plain install.packages("renv").

When working within an renv project, the version of renv installed in that project is normally the copy that is used -- so at this point, it should no longer matter what version of renv is installed in the user library.

On a more conceptual level: why is renv itself part of the virtual environment it creates? That's not the case for the python virtual environment managers I know.

This is done primarily to ensure existing renv projects can continue to function even if an update to renv happened to break some existing workflows. (We endeavor to make sure that will never happen, but want to make sure users have an escape hatch in case it does.)

However, when I do not have renv installed, and clone a repo that uses renv, it seems to install (bootstrap?) itself. But it does this within the local renv environment.

The "bootstrap" behavior here is done to help streamline the collaborative workflow. Rather than requiring users explicitly install renv before opening an renv project, renv knows enough to bootstrap itself in an existing project so that new users can get up and running quickly. (In addition, the bootstrapper script also tries to ensure that the version of renv that project was configured to use is installed.)