Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate using / supporting renv with R #660

Open
yuvipanda opened this issue May 1, 2019 · 10 comments
Open

Investigate using / supporting renv with R #660

yuvipanda opened this issue May 1, 2019 · 10 comments

Comments

@yuvipanda
Copy link
Collaborator

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.

@betatim
Copy link
Member

betatim commented May 2, 2019

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.

@yuvipanda
Copy link
Collaborator Author

I like it. /cc @karthik @cboettig

@cboettig
Copy link

cboettig commented May 2, 2019

Looks pretty good to me.

Curious what you think of https://rstudio.github.io/renv/articles/python.html?

@cboettig
Copy link

cboettig commented May 2, 2019

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 :-) ).

@karthik
Copy link

karthik commented May 2, 2019

I approve using renv. Happy to contribute some effort here.

@betatim
Copy link
Member

betatim commented May 3, 2019

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.

@yuvipanda
Copy link
Collaborator Author

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.

@betatim
Copy link
Member

betatim commented May 3, 2019

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.

@nuest
Copy link
Contributor

nuest commented Sep 17, 2019

Just keep in mind: if composable build packs get re-introduced, then the "should take precedence" must be realised somehow.

@kaedonkers
Copy link

kaedonkers commented Aug 16, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants