Releasing repo2docker v0.11.0

Binder
,
1

Another announcement from the Binder team: this morning we released v0.11 of repo2docker :tada:!

You can update or install it with:

pip install -U jupyter-repo2docker

A complete list of changes and new features is here.

The feature I am most excited about is that we now automatically install RStudio for you when we detect that you are using R packages in your environment.yml. This means you can now also use the pre-built packages from conda-forge for your R packages instead of using only install.R. This will hopefully speed up repository build times as the conda-forge packages are binaries and don’t need compiling from scratch like the CRAN packages. An example repository to get you started with this is https://github.com/betatim/r-conda.

Help us make mybinder.org better by taking the mybinder.org user survey.

Happy repo2docker’ing!

5 Likes
2

"we now automatically install RStudio for you when we detect that you are using R packages in your environment.yml"

Out of interest, can that autoinstall be disabled?

3

Right now no. The thinking is that a large fraction of people who install R packages via conda are R users and hence like having RStudio (even preferred over using Jupyter notebooks as UI).

Can you explain a bit why you want to disable it?

4

On https://github.com/krassowski/jupyterlab-lsp, we use r-languageserver from conda-forge, but aren’t particularly interested in rstudio. It did seem a bit heavy the first time I used it, but :woman_shrugging:. Could it be moved further up the stack so that it disappeared into the layer cache?

5

I think it is as far up as it can be. We have done all the generic things and look at the environment.yml for the first time, but before the layers that are invalidated by changes in your repository.

I think to install RStudio you need a working R binary, so we can’t do it before installing the rest of the conda env.

Maybe a way out is to not trigger this functionality if only “special” conda packages are in the envrionment.yml (like r-languageserver).

6

I wouldn’t worry about it for our case: we install other stuff, and will probably install more as we get things working. I suppose if we get super grumpy we could have our own Dockerfile.

Maybe a longer-term option would be binder/.optout file or something… but I know part of the idea was to not have “bespoke” files, and just do the Right Thing.

1 Like
7

Re: why disable it:

  • teaching situation, materials delivered as R notebooks, don’t want students getting distracted;
  • image weight: if R notebooks is my context, why add weight to the image with apps I don’t need. (A lot of our students are on underspecced machines and image weight can get to be an issue.)

Generally, I agree RStudio could be handy. But there are some cases where it may be more convenient not to make it available.

(I don’t know, but in some situations I could imagine licensing or IT security folk to want to sign off on everything in an image, and every extra application in the image adds another step to the sign off. (And yes, I know, if those folk were paying attention, they’d want to see a custom Dockerfile not a repo2docker generated one, unless repo2docker itself had been signed off…)

8

Hmmm… thinks… I guess there are two parts to adding RStudio:

  1. installing it into the image;
  2. making it available from Jupyter UI.

I guess in edu context I could add a postBuild to disable the RStudio serverproxy extension which you presumably do run?