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:
renv.lock, but also the .RProfile and renv/activate.Rrenv.lockApparently 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)?
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.