RStudio (or OpenRefine?) as default interactive application on empty repo

I’m working on integration of repo2docker into Whole Tale and have some additional questions about Rstudio
and other non-Jupyter interactive applications. This is tangential to my comment in repo2docker/#533.

Currently, WT treats the Jupyter and RStudio (and OpenRefine) environments separately. We provide base images for each and when the user selects their default interactive environment, they start from the associated image – even on an empty “repo”. WT supports the use case of a user starting from a blank workspace with their interactive environment of choice.

In the case of RStudio, repo2docker only installs the package if it detects an R buildpack file (runtime.txt, DESCRIPTION, Stencilia context, etc). Given an empty repo, repo2docker provides a Jupyter environment by default. While I can override the command at runtime (per issue #533), I don’t appear to be able to tell repo2docker to install RStudio by default. The OpenRefine example uses a postBuild script.

I’m not sure how best to approach this in WT. A couple of options come to mind:

  1. When the user creates a new “Tale” (our equivalent of the Binder repo), we could initialize it with appropriate buildpack files on their behalf – maybe the runtime.txt for R and postBuild script for OpenRefine.
  2. Modify repo2docker to enable alternative default interactive applications (also somewhat related to #545 and #546) – this would require some option for installing by default. At this point, I think Jupyter, RStudio, OpenRefine and noVNC/Xpra are our main cases – with Jupyter and RStudio clearly dominant.

I’m open to the idea of WT implementing the repo2docker reproducibility best-practices and always creating a “pinned” environment, which means #1 is a reasonable approach. I can also see this as a case for expanding repo2docker to enable alternative default interactive environments.

One thing you can do is adjust the Repo2Docker.default_buildpack configuration to be a different buildpack when no environment specification is found. You may find, however, that some buildpacks other than the default make assumptions that certain files are present. This would be a bug, I think.

deployment-configurable defaults in repo2docker are a tricky one. On the one hand, it makes sense from an audience-specific deployment case (it’s annoying for all your users to have to specify openrefine if everyone is using that), on the other it’s a nightmare for portability (this repo worked on WT repo2docker, but not repo2docker).

So I’d probably aim at 1. and look at a way in repo2docker to make that as easy as possible.

Thanks @minrk. I’ve been looking at default_buildpack and agree that having a WT-specific configuration would likely create more problems. Aside from portability, for reproducibility/provenance we’d need to include a reference to the custom configuration in the published artifact. Trying to stick to a common configuration seems like the best approach.

What about allowing the repo to declare the default application should be RStudio – aside from the urlpath parameter in the badge/link? For example, might open Rstudio by default when the repo URL is pasted into

That’s possible. We’ll have to think about whether that can be truly generic (setting arbitrary launch command) vs picking from a supported list