5

I am trying to get me and my colleagues started on using renv. I have found different pieces of information of what should/can be committed to git for collaboration:

  1. the renv collaboration vignette suggests to not only commit the renv.lock, but also the .RProfile and renv/activate.R
  2. it is however possible to only commit renv.lock

Apparently there was also some discussion from the developers on which strategy to use.

In general (and coming from pyhton, where basically a requirements.txt is sufficient), I quite like approach 2. Are there any drawbacks to it? Any changes in what the collaborator then has to do (e.g. start with renv::restore or with renv::init)?

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
gira
  • 175
  • 6
  • "*…coming from pyhton, where basically a `requirements.txt` is sufficient…*" Not exactly true, sorry. `requirements.txt` should contain the result of `pip freeze`, i.e. the full list of packages with dependencies and exact versions. While `requirements.in` should contain only top-level packages with inexact versions or ranges. `requirements.in` is usually created by hand and `requirements.txt`is generated automatically. Plus `Pipfile` plus `Pipfile.lock`. Oops… – phd Oct 11 '22 at 08:33
  • In addition to the comment by @phd, `requirements.txt` is really a minimum effort and is generally *completely insufficient* to generate an isolated environment. Python has other ways for this (some of which do this a lot better than R + ‘renv’) but `requirements.txt` isn’t it. – Konrad Rudolph Oct 11 '22 at 08:35
  • fair, my comparison to `requirements.txt` wasn't the best one – gira Oct 11 '22 at 09:04

1 Answers1

5

The drawback to only committing renv.lock is that ‘renv’ won’t be activated automatically when the project is loaded in the usual way, which means that collaborators might accidentally be running code from the project outside the confines of the environment.

Whether this is a problem mainly depends on your internal processes, i.e. how the project will be used. Having some kind of “enforcement” by automatically loading ‘renv’ can definitely be useful, and has essentially no drawbacks — so why not just commit the additional two files?

On the other hand, it should be noted that committing the .Rprofile and renv/activate.R files also doesn’t guarantee that these will be loaded every time the project is loaded. There are unfortunately many scenarios in which R code is executed without automatically sourcing the .Rprofile file associated with a project directory (in fact, it’s only sourced under very specific circumstances; namely, when the current working directory is set to the project directory). But it’s still better than nothing.

In sum, I don’t see a good reason not to commit all these files if you commit renv.lock.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214