Add debian:stable based Dockerfiles for specific R versions

[cboettig]

Hey @wch ,

Just a thought since we've been seeing this request a bunch recently. (eg @nihonjinrxs).

Here's a proposal which would create version-stable tags based on the underlying R version, e.g. rocker/shiny:3.3.2 and rocker/shiny:3.3.1 images. These build on debian:stable (so no -t unstable switching needed for these as packages debs migrate out of unstable and break things). The r-ver image also sets an env var for MRAN pointing at the MRAN snapshot matching the day that version of R was last current, letting a user install R packages corresponding to the older version of R. This should give users concerned about reproducibility a bit more version-stable option.

I can create the tags in Docker hub if you like this, otherwise feel free to turn it down if it looks like more complexity than necessary. The r-ver stack seems to have gone over well so I thought I'd at least give this a pitch.

[nihonjinrxs]

@wch, I just want to indicate my need for a version-stable shiny image. I need to have reproducible containers for production deployment to be able to ensure service continuity and replicate for debugging, and rocker/shiny is a current hole for doing that on our production infrastructure.

Thanks, @cboettig, for the solution here.

(edited to remove second and add indicate)

[eddelbuettel]

Sorry, but you are not seconding this. You already reported this, simply in another venue. Carl did you the favour of carrying it over here on your behalf.

I, on the margin, still think both things are of mostly local interest only (but then I also do not care about MRAN and GRAN and whatnot) If you happen to have a production need, I would expect you to go out and fix it. What we do here consumes public and private resources, has an impact on our attention span and possibly crowds out others projects. Few things are genuinely limitless.

But hey, the shiny containers are Winston's baby so he gets to make that call.

[nihonjinrxs]

@eddelbuettel, I'm not sure what I did to earn so much hostility from you, but I don't think it's warranted. I can't believe I'm the only one experiencing the need, and I am doing what I can to fix it in my own context, but thought it would be nice for the source I'm working with to have that fix available out of the box. I'll keep quiet now, and let you all figure out what you want to do.

[eddelbuettel]

I was not, and am not singling you out. I was merely correcting your "seconded" as you are "first and so for only" public supporter of it.

But as Carl said, the versioning (of basic Docker images for R) proved popular with other people so if someone (you?) wants to do the work, go for it. But please keep in mind that we all have other jobs, projects and hobbies. So people tend to work on stuff that motivates them. And as you can probably tell by now, I find versioning by Docker to be lacking in that regard. But that's just me. Go crazy, if you must.

[nihonjinrxs]

Comment above corrected.

[jpds]

Could we possibly have this merged please? I have the same issues as the person in #25.

[shapiromatron]

I could use this as well; if there's something that needs to be done to get this ready for acceptance, let us know, we may be able to help.

[shapiromatron]

I have a versioned 3.4.3 version which works; can contribute to this PR if it's likely be accepted.

[cboettig]

Note that you can add shiny at runtime to existing rocker-versioned images using -e ADD=shiny, e.g.

docker run -p 8787:8787 -e ADD=shiny rocker/rstudio:3.4.2

Guess that's not well documented though.

[nihonjinrxs]

@cboettig Thanks. Wasn't aware of that. Seems like since this happens at runtime, it doesn't work so well when using the image as the base image for a new Dockerfile, though, correct?

[cboettig]

@nihonjinrxs This runtime argument will work on your image if it is based based on rocker/rstudio or any of the derivatives in the versioned stack, e.g. rocker/tidyverse etc.

But if you are writing your own Dockerfile based on the stack, it's better to simply include the line:

RUN export ADD="shiny" && bash /etc/cont-init.d/add

which will tell Docker to add shiny when your image is built.

[shapiromatron]

I don't think I want rstudio server running or remote connections executing code in a server-hosted R environment (other than the shiny apps) - I'd still prefer to have a versioned shiny only docker image...

[cboettig]

@shapiromatron fair enough. There's no reason to have rstudio start if you don't want to, just change your default run command. For instance, if you've installed shiny in a custom Dockerfile as described above, then:

docker run -p 3838:3838 your-image shiny-server

will by-pass the default init system that brings up RStudio, so only Shiny will run. Note that docker only opens the remote connections you tell it to.

[shapiromatron]

@cboettig Oh, that sounds like it might work; sorry I'm not as familiar with the rstudio suite so I wasn't sure if it was an all or nothing thing.

I'll try using this route; if it works for me should I submit a PR to update the docs on this repository for an approach to take if you want a debian:stable shiny build?

[cboettig]

Thanks, that would be great; appreciate your testing and feedback!

[shapiromatron]

@cboettig worked like a charm, thanks.

@wch (or others) I submitted an alternative request, #31, which just updates the docs for how users can get a debian-stable and pinned R-version shiny server; no code changes just docs.

[nihonjinrxs]

@cboettig Thanks for this. I'll give it a shot.

[wch]

Hi all, sorry for being absent from the discussion here. I've been meaning to respond to this for ages. I have too much stuff on my plate these days to maintain changes like this, so if @cboettig (or someone else) wants to handle it going forward, I'd be happy to help make that happen.

[cboettig]

Ok, updating and merging this to allow shiny to build on versioned stack. 🚢

[nihonjinrxs]

Thanks so much!