Docker install scripts

[sckott]

Work on giving user ability to install R/rstudio etc. via docker

[sckott]

See @cboettig comments https://github.com/sckott/analogsea/issues/17#issuecomment-53317455

[hadley]

I think we have the needed infrastructure for this now. Do you want me to convert the existing scripts in rinstall.r?

[sckott]

yeah, sounds good!

[hadley]

Looking at rinstall.r more seriously, maybe we can just delete it all? I think the majority of use cases are covered by docklet_pull() with the right dockerfile.

[sckott]

Sure, sounds good

[hadley]

I keep going back and forth on this. There will be a number of scenarios where adding docker into the mix will just add more overhead for little gain. But if we keep this code, we end up with quite a bit of duplication, because everything here will also be in a docker file. Any thoughts @cboettig ?

[cboettig]

you're thinking cases that just need basic r, where installing would be faster than pulling down a docker image? Or other scenarios as well?

I'm tempted to stick with the docker-only. Having two mechanisms might make it harder to debug user issues, or distinguishing when a feature is only available in docker mode.

It has some portability advantages in being a consistent environment regardless of the host OS chosen for the droplet, etc, though that doesn't matter much in this context.

If we have or encounter other compelling use cases we should definitely consider the install script of course.

---

Carl Boettiger http://carlboettiger.info

sent from mobile device; my apologies for any terseness or typos On Oct 2, 2014 5:45 AM, "Hadley Wickham" notifications@github.com wrote:

I keep going back and forth on this. There will be a number of scenarios where adding docker into the mix will just add more overhead for little gain. But if we keep this code, we end up with quite a bit of duplication, because everything here will also be in a docker file. Any thoughts @cboettig https://github.com/cboettig ?

— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/18#issuecomment-57624105.

[hadley]

@cboettig sometimes you just want R running on a remote server. If everything is done through docker you going to need to learn quite a lot of new stuff - e.g. how can you install packages once and make them available across multiple sessions?

[cboettig]

Ah, right. changes you make last until the container is destroyed (e.g. docker stop hash and docker rm hash). Of course if your running as docker run --rm -t imagename Rsrcript ... the container is being destroyed (rm) when it stops. If you omit the rm it persists along with it's state (I think you use docker start instead of docker run then to get it back). If you run in daemon mode, e.g. for rstudio, the container is always running so changes persist. When you reboot, all containers are stopped but not destroyed, I believe you have to manually restart them. Not sure if that answered your question

---

Carl Boettiger http://carlboettiger.info

sent from mobile device; my apologies for any terseness or typos On Oct 2, 2014 6:48 AM, "Hadley Wickham" notifications@github.com wrote:

@cboettig https://github.com/cboettig sometimes you just want R running on a remote server. If everything is done through docker you going to need to learn quite a lot of new stuff - e.g. how can you install packages once and make them available across multiple sessions?

— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/18#issuecomment-57631804.

[sckott]

I kind of like the idea of being able to just have R running on a remote server I imagine docker is probably the better solution, but I could imagine that some may want to do it all from scratch.

[hadley]

@cboettig yes, I understand how you might solve the problem (attaching a persistent data volume just for storing packages is another solution), but it's quite a lot for someone to take in.

Also, I'm reasonably certain that docker start won't help here - it will start a stopped container, but you can't send an additional command. A container is fundamentally ephemeral. Even when running RStudio, the user should be guided to make changes on persistent storage outside of the container, or at least have some easy way to capture state.

[hadley]

@sckott I think I'll break up rinstall.r into multiple functions, and add a bit of infrastructure so it's easier to see what's going on. It's a bit too indirect for my taste right now

[cboettig]

Right, sounds good.

A way to commit and export your container would be good, either to the hub or download locally, since it could then persist beyond the life of the droplet.

---

Carl Boettiger http://carlboettiger.info

sent from mobile device; my apologies for any terseness or typos On Oct 2, 2014 7:05 AM, "Hadley Wickham" notifications@github.com wrote:

@sckott https://github.com/sckott I think I'll break up rinstall.r into multiple functions, and add a bit of infrastructure so it's easier to see what's going on. It's a bit too indirect for my taste right now

— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/18#issuecomment-57634377.

[sckott]

okay, thanks @hadley

[hadley]

Take a look at https://github.com/sckott/analogsea/commit/a78f68bdaf2565467b3b866d9e3d45cb2a4fb99e and let me know what you think - I haven't tested anything yet, but I think this refactoring makes it quite a bit easier to see what's going on. I also think it's better design to have multiple simple functions rather than one big complicated one.

[sckott]

I agree, smaller rather than larger functions, I'm still working on writing better code :)

Looks good to me!