RStudio-based Docker image

[kevinwang09]

Thanks a lot for the great tools! I want to know if you can provide a Docker image with RStudio installed and all the dynverse set up?

I have tried this, but I hit a roadblock when running the trajectory constructions as that will try to pull a docker image inside a working RStudio docker image. Which is difficult to set up. Many thanks

[rcannood]

We ran into this issue ourselves as well, in trying to create a Docker containing all dynverse packages required to run a TI analysis. As far as I know, it is not really feasible to run a Docker inside a Docker.

One possibility would be to try to create a single Docker with as many TI methods installed as possible. It would not be possible, or at least very difficult, to install all TI methods inside this single container because some of them have directly conflicting dependency requirements. However, this would require significant changes to the current codebase.

[jfx319]

...TI methods ... have directly conflicting dependency requirements

likewise, dyno itself is not immune to conflicting dependency requirements, reproducibility, versioning, etc; so ultimately in the spirit of the OP's question, it is preferable to have as an option: dyno in its own isolated environment (probably its own container)

...it is not really feasible to run a Docker inside a Docker

maybe this doesn't have to be the goal?

IMO, having TI-methods containerized, and importantly standardized to dynverse is already more than half the value! The remaining would be reaping the fruits of standardization via dyno. The marginal burden of manually connecting the two is minimal and a small price to pay, if all that were needed is a (two)-piecemeal user intervention to connect the two, while keeping both safely isolated from a deliberate installation.

What about something like this:

• rocker-based container with dyno + shiny setup -> users can use this to output standardized intermediates: wrapped dataset, guidelines, etc
• commandline helper scripts (R, bash, python, etc similar to KlugerLab/FIt-SNE) for running individual TI-methods containers using the standardized objects as a starting point, similar to #59
  • the key realization here is that dependency conflicts will always be a thing and grows unpredictably the more packages that are installed in the same environment; no need to package them together if they will run independently anyway; keeping them separate actually makes cluster jobs easier to scatter/join and makes it flexible for HPC users to control/orchestrate
• analyze/visualize the outputs back in the dyno container, once individual methods have finished and written their outputs to a mounted folder