repo2docker
repo2docker copied to clipboard
Investigate using / supporting renv with R
Proposed change
https://rstudio.github.io/renv/ seems to be a new way to do isolated package dependencies in R from the wonderful folks at RStudio. We should investigate it to see if there's any use repo2docker can get out of that.
Alternative options
The current similar alternative is packrat, which is a lot more heavyweight and not particularly popularly used (from what I'm told).
Who would use this feature?
R folks who want isolated environments, like virtualenvs. I am not entirely sure how that fits into repo2docker, since we already use containers.
One way to use this is to support/detect the presence of a renv.lock and use that to install packages instead of install.R (or as a small step towards phasing out that file).
From reading their website for a bit: it would be interesting to know why they don't have a renv where you can write down what packages you want and them from that generate the lockfile renv.lock.
I like it. /cc @karthik @cboettig
Looks pretty good to me.
Curious what you think of https://rstudio.github.io/renv/articles/python.html?
From reading their website for a bit: it would be interesting to know why they don't have a renv where you can write down what packages you want and them from that generate the lockfile renv.lock.
I believe renv is following packrat method of detecting all dependencies based on finding library() calls in the code (and then computing the recursive dependencies); probably based on the reasonable assumption that going by actual library() calls found in the user's code will be more accurate than assuming users actually remember to add each package manually to some new config file. (Looks like it will similarly generate a requirements.txt from R code that requires python packages :-) ).
I approve using renv. Happy to contribute some effort here.
What do people think of making a new build pack (that inherits from the R build pack) that detects the renv.lock, installs the renv package, and then runs renv::restore().
We already support requirements.txt so we should make sure to set renv (and reticulate?) to use the conda env that would be created if a requirements.txt is found in the repository.
I like it, @betatim. I think renv.lock should take precedence over install.R, so maybe renv.locks' buildpack should be inherited by the current one? Doesn't matter too much though.
I think of precedence being defined by the order that build packs are searched and inheritance for composing the different (compatible) environments. In my mind we'd reuse some of the infrastructure from the existing R build pack (how does the R binary get installed, RStudio, etc) but the packages that get installed come from renv.lock instead of install.R.
Just keep in mind: if composable build packs get re-introduced, then the "should take precedence" must be realised somehow.
Hi. I've been working on using renv in my implementation of Binder and was wondering what the status of this feature was?
My workaround was to include renv::restore() in my postBuild script, which seems to work well enough:
https://github.com/informatics-lab/binder_rstudio_jupyterlab_example/blob/main/.binder/postBuild
However, including renv::restore() into the build would speed up instantiation of a binder without having to run renv::restore() every time.