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
I’m not sure how best to approach this in WT. A couple of options come to mind:
- 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.txtfor R and
postBuildscript for OpenRefine.
repo2dockerto 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.