rocker-org / rocker

R configurations for Docker

rocker

Overview

This repository contains Dockerfiles for different Docker containers of interest to R users.

Getting Started

To get started right away, ensure you have Docker installed and start a container with docker run --rm -ti rocker/r-base (see here for the docker run command options). In this case we are starting the r-base container (the base package to build from) in an interactive mode, see below for details of the other containers currently available. To get started on the rstudio container or its derivative containers (eg. hadleyverse and ropensci) you need to open a port, see the instructions in the wiki. The wiki also contains further instructions and information on the project, including how to extend these images and contribute to development.

Status

This is work in progress; please read our instructions to contributors and talk to @eddelbuettel and @cboettig about how to get involved.

Base Docker Containers

image	description	size	metrics	build status
r-base	Current R via apt-get with debian:testing & unstable repos
r-devel	R-devel added side-by-side onto r-base (using alias RD)
drd	lighter r-devel, built not quite daily
r-ver	Specify R version in docker tag. Builds on debian:stable

Use cases

The rocker project also hosts Docker images illustrating particular use cases. More information about these can be found in their respective respositories on rocker-org

Unversioned images (builds on r-base)

image	description	size	metrics	build status
r-devel-san	as r-devel, but built with compiler sanitizers
r-devel-ubsan-clang	Sanitizers, clang c compiler (instead of gcc)
rstudio:testing	rstudio on debian:testing
shiny	shiny-server on r-base
r-apt	(R plus CRAN + marutter repo information)

Versioned stack (builds on r-ver)

These images build on rocker/r-ver. Each of these include tags to specify the desired version of R, e.g :4.0.0, :latest, :devel. See rocker-versioned2 repo for details. R 3.x versions are built from the older recipes in rocker-versioned

image	description	size	metrics	build status
rstudio	Adds rstudio
tidyverse	Adds tidyverse & devtools
verse	Adds tex & publishing-related packages
geospatial	Adds geospatial libraries

Anyone interested in proposing or collaborating on additional use cases should read our guide to contributing and get in touch

License

The Dockerfiles in this repository are licensed under the GPL 2 or later.

Trademarks

RStudio is a registered trademark of RStudio, Inc. The use of the trademarked term RStudio and the distribution of the RStudio binaries through the images hosted on hub.docker.com has been granted by explicit permission of RStudio. Please review RStudio's trademark use policy and address inquiries about further distribution or other questions to [email protected].

rocker's Issues

Clean out /var/lib/apt/lists/

Not sure if it's worth the trouble, but apparently you can save ~10MB with rm -rf /var/lib/apt/lists/*:
http://jonathan.bergknoff.com/journal/building-good-docker-images

Rstudio container becomes unresponsive after long runs

I'm using the rocker/rstudio container on an openSuSE 13.1 system. The machine has 16 hyperthreaded cores with 128GB RAM. The container is being accessed remotely from two different Windows 7 systems using both Chrome and Explorer.

The command issued on Linux was
docker run -d -p 8787:8787 rocker/rstudio
docker run -d -p 8788:8787 rocker/rstudio
docker run -d -p 8789:8787 rocker/rstudio

to start three different sessions.

docker was installed following the instructions for openSuSE on the docker github page.

The error is as follows:

Initially, you can log in and execute commands. The command executed in R in this case is:

source("http://bioconductor.org/biocLite.R")
biocLite(all_group())

This runs for a little while and then becomes unresponsive -> the web page will not refresh and subsequent attempts to correct result in a cannot load web page error.

Here are the logs:

/home/dnadave> docker logs 007b731f4cc3
/usr/lib/python2.7/dist-packages/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
'Supervisord is running as root and it is searching '
2014-11-05 21:43:21,422 CRIT Supervisor running as root (no user in config file)
2014-11-05 21:43:21,423 WARN Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
2014-11-05 21:43:21,437 INFO RPC interface 'supervisor' initialized
2014-11-05 21:43:21,437 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-11-05 21:43:21,437 INFO supervisord started with pid 1
2014-11-05 21:43:22,441 INFO spawned: 'rserver' with pid 8
2014-11-05 21:43:22,443 INFO spawned: 'userconf' with pid 9
2014-11-05 21:43:22,473 INFO exited: rserver (exit status 0; not expected)
2014-11-05 21:43:23,132 INFO exited: userconf (exit status 0; not expected)
2014-11-05 21:43:24,135 INFO spawned: 'rserver' with pid 53
2014-11-05 21:43:24,137 INFO spawned: 'userconf' with pid 54
2014-11-05 21:43:24,149 INFO exited: rserver (exit status 0; not expected)
2014-11-05 21:43:24,227 INFO exited: userconf (exit status 0; not expected)
2014-11-05 21:43:24,460 CRIT reaped unknown pid 56)
2014-11-05 21:43:26,464 INFO spawned: 'rserver' with pid 81
2014-11-05 21:43:26,466 INFO spawned: 'userconf' with pid 82
2014-11-05 21:43:26,477 INFO exited: rserver (exit status 0; not expected)
2014-11-05 21:43:26,553 INFO exited: userconf (exit status 0; not expected)
2014-11-05 21:43:26,788 CRIT reaped unknown pid 85)
2014-11-05 21:43:29,794 INFO spawned: 'rserver' with pid 109
2014-11-05 21:43:29,796 INFO spawned: 'userconf' with pid 110
2014-11-05 21:43:29,808 INFO exited: rserver (exit status 0; not expected)
2014-11-05 21:43:29,809 INFO gave up: rserver entered FATAL state, too many start retries too quickly
2014-11-05 21:43:29,890 INFO exited: userconf (exit status 0; not expected)
2014-11-05 21:43:30,119 INFO gave up: userconf entered FATAL state, too many start retries too quickly
2014-11-05 21:43:30,120 CRIT reaped unknown pid 112)

reproducibility wrt CRAN vs Debian binaries of packages?

@eddelbuettel Wanted to get your perspective on a reproducibility issue in the Dockerfile design. One interesting Docker use-case for me is being able to run code from a paper of several years ago. (e.g. code in several of my own papers are no longer trivial to execute successfully due to packages that have been archived from CRAN or otherwise updated in a way that breaks backwards compatibility). I realize that the only robust solution to this is to have the binary image archived, but keep wondering how well one could do from just an appropriately constructed dockerfile.

For instance, it seems to me that installing from the debian repositories is somewhat more stable than installing from CRAN -- e.g. given a Dockerfile that fixes a Debian release (e.g. jessie) and the sources.list file, apt-get install r-cran-<package> will continue to work even if the package is archived from CRAN?

Best-practices tweaks to Dockerfiles

The Best-practices repo suggests we

• Avoid ever using apt-get dist-upgrade
• Update on the same line as any install call, e.g. RUN apt-get update && apt-get install -y, such that the cache is always invalidated and the latest versions of those packages will thus be installed.
• List each install on a new line (with \), sorted alphanumerically...

Other than that, we're more-or-less doing okay.

• I should see if I can use an ENTRYPOINT in rstudio to run the script, rather than the current supervisord thing, in order to get a persistent rstudio instance running. (one disadvantage is that I believe that would run the script to launch RStudio even when the container is run interactively)

I'm also warming up to the idea of just canning the Ubuntu branch and being able to simplify the namespace and the complexity of the project in general as a result...

Typo in removing /tmp/R-devel

Just noticed this:

$ docker run rocker/r-devel du -s /tmp/R-devel
226828  /tmp/R-devel

The problem is that the Dockerfile has rm -rf /tmp/r-devel instead of rm -rf /tmp/R-devel.

Default locale is C

This is in the eddelbuettel/ubuntu-rstudio image:

> Sys.getlocale(category = "LC_ALL")
[1] "C"

For best interoperability, it should be UTF-8.

Some information about it here:
http://jaredmarkell.com/docker-and-locales/
https://crosbymichael.com/dockerfile-best-practices-take-2.html

wish: images by r versions

Hello,

It would be nice to able to to get a fixed version of R, e.g. R-3.0, R-3.1, and even more specific like R-3.0.2.

Thanks for your work,

Non-root users, shared volumes, & RStudio

Docker does some kinda unexpected things when it comes to handling non-root users and shared volumes. With the rstudio image, we have to create a non-root user with a password that can be set at runtime for security purposes, which we do by running a custom userconf.sh on startup.

RStudio wants to start in the users home directory (regardless of the value of --workdir). First crazy thing is: if the userconf.sh script does not run a chown command (as we have currently), that directory is not owned by the user rstudio (or other user specified with the environment variable $USER. Lacking write permissions, RStudio cannot even start up. Surprisingly, the directory /home/rstudio is owned by the user docker!

If we run chown -R $USER:$USER /home/$USER at the end of the userconf.sh script, RStudio can now log in. But if we have linked a home directory, chowning to anything other than the the docker user (Why the docker user? Just the first non-root user added to docker?) means that the permissions on the linked directory outside of the container will be changed to some other user. Attempting to match the host user name with the $USER value on the container isn't any different than just leaving the container $USER as docker.

The only way out of this that I see is to have only one user (e.g. hardwire the user docker, and just set the password interactively. breaks previous instructions and feels inelegant). Can't be sure if this problem existed before we added a default user docker, perhaps removing that would avoid these issues?

Anyway, curious if you might confirm any of this behavior, and I'll see what I can come up with.

Configure such that a non-root user can install packages to /usr/local/lib/R/site.library

• Looks like the user may have to be added to the staff group first: useradd username staff (requires we know the username)
• Adding user to staff group doesn't seem sufficient?
• on some containers (ubuntu-hadleyverse), seems like /usr/local/lib/R/site.library isn't owned by the staff group, but just by user. This doesn't seem true for the other repos I tested though (e.g. ubuntu-rstudio).

License?

Should we declare a license for the repo? If so, what license?

I see your point that configuration scripts aren't really software, but there seems to be a good case in wanting the terms of reuse for just about anything to be clearly stated. It looks like official Dockerfiles are using the MIT license, which would be my preference. (For consistency with community practice, maximizing reuse, and providing the minimal disclaimer text about "AS-IS" etc). I know you usually go with GPL, so I'm happy to be convinced otherwise.

I suppose it is clear that the license applies only to the Dockerfile, that the image itself contains it's own licenses and that we/dockerhub have the rights to redistribute them...

tuning the hadleyverse repo

@hadley Currently hadleyverse uses the current CRAN versions for all packages, including CRAN versions of all packages on the SUGGESTS lists (as opposed to whatever is available as debian binaries, etc), with the exception of reshape2, because not having hadley/reshape#46 fixed kills me). Curious if you think it might be handy to use the github versions of other packages, either by default or maybe as a hadleyverse:dev tag, or if you think most users are best off with the CRAN versions (since they can always explicitly upgrade later). Thanks for your input!

Mapping out the component dockerfiles and their dependencies?

Wondering if we shouldn't do a bit of brainstorming about how best to nest the different Dockerfiles before we get started. It seems like we have an interest in building two trees: an Ubuntu-based one and a Debian based one.

From the Dockerfiles we already have, the current structure of a given tree looks something like this:

- ubuntu 
  - add-r 
    - add-r-devel
    - add-r-devel-san
    - rstudio
      - ropensci
      - swc
- debian 
  - ...

This isn't a bad structure, but particularly out near the twigs there's some redundancy and room for shuffling. For instance, ropensci has a lot of the compiler/tex dependencies found in add-r-devel (actually it currently has everything in r-devel). swc could use the larger ropensci as a base (e.g. to share the compile tools, or so that the knit2pdf button on rstudio will actually work).

Offering too many images might be overwhelming to users, but smaller more modular dockerfiles might also be easier to maintain. Lots to think about I guess.

"Unable to connect to service" when attempting to mount volume.

Hi,

I've tried this on a few different machines, and am consistently met with an "Unable to connect to service" error. It only seems to happen when I share a volume.

I'm building the docker image from master.

Let me know what other info I can provide.

Set a non-root user by default?

As suggested in pachadotdev/analogsea#25 (comment)

I'm really not sure what the best way to add a user is, in general. You can give user as an option at runtime e.g.: docker run --user me -it ubuntu:latest bash, but you'll just get an error that the user doesn't exist.

I can throw a RUN useradd user into the Dockerfile, but then at runtime you'd have to know to use --user user. (Maybe that's best for the analogsea case where we can set defaults for runtime).

I could instead add the [USER] user directive into the Dockerfile, but then anyone who tries to build on the Dockerfile (including all of our dockerfiles) will need to start off with a [USER] root or will get a permission denied from their RUN apt-get lines, etc.

In rstudio image and above, the rstudio user is created only at runtime by the userconf script. I had this hardwired into the Dockerfile earlier and had it create some strange behavior when trying to run the container with a different user (specified in the commandline arguments). When logging in via RStudio a user is never root.

r-devel: How do I access the development version?

In the r-devel image, the R version accessible from the PATH seems to be that from the Debian packages:

# docker run rocker/r-devel /usr/local/lib/R/bin/R --version
R Under development (unstable) (2014-10-18 r66793) -- "Unsuffered Consequences"
Copyright (C) 2014 ...

# docker run rocker/r-devel Rdevel --version
R Under development (unstable) (2014-10-18 r66793) -- "Unsuffered Consequences"
Copyright (C) 2014 ...

# docker run rocker/r-devel R --version
R version 3.1.1 (2014-07-10) -- "Sock it to Me"
Copyright (C) 2014 ...

Do we really need both R and R-devel in this container? Perhaps it's possible to choose the R version by a tag (cf. #16, http://blog.docker.com/2014/09/docker-hub-official-repos-announcing-language-stacks/), and leave the name of the main executables unchanged?

Linked builds

Ooh, looks like docker hub also supports linked builds. Presumably this will ensure that changes to say, r-base, propagate to rstudio, hadleveryse, ropensci etc by having them build successively, rather than in parallel.

Also seems reasonable to link r-base to the latest debian image? e.g.

https://registry.hub.docker.com/u/rocker/r-base/settings/links/

or not?

rstudio/rstudio not working

Hi,

I could not login w/ rstudio/rstudio. I think it is related to #59. Or at least, I reverted the changes then was able to login.

Let me know if I can provide more info.

Query and install the latest RStudio version

Currently we've hardwired in a particular RStudio deb file. @wch points out:

I'm told that you can get the latest RStudio version by looking at this URL:
https://s3.amazonaws.com/rstudio-server/current.ver

And with that info, you can get the URL for latest RStudio build.

libpath for RD --vanilla lacks /usr/lib/R/library

As discussed in #54, the reason for R-devel to use /usr/lib/R/library is so that it can use some standard packages installed via .deb packages, even though they're for R-release.

However, when RD --vanilla is used, that directory is not added to the libpath. Here's what happens when you don't use --vanilla -- everything works as expected:

$ docker run --rm rocker/r-devel RDscript -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     
[3] "/usr/lib/R/library"           

$ docker run --rm rocker/r-devel RDscript -e "library(MASS)"
[No output]

When you use --vanilla, here's what happens when you try to do the same things:

$ docker run --rm rocker/r-devel RDscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     

$ docker run --rm rocker/r-devel RDscript --vanilla -e "library(MASS)"
Error in library(MASS) : there is no package called ‘MASS’
Execution halted

In my case, this results in problems for RD CMD check --as-cran, because it uses --vanilla, and many times, the check requires standard packages like MASS and codetools, which reside in /usr/lib/R/library.

I think it makes more sense for the libpath to be the same whether or not you use --vanilla.

I believe the way to fix this is to set the R_LIBS in Renviron instead of setting R_LIBS_SITE in Renviron.site, which is what is currently done in the Dockerfile. For example:

$ docker run --rm -ti rocker/r-devel
# RDscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"  

# cd /usr/local/lib/R/etc

# echo "R_LIBS=\${R_LIBS-'/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib/R/library'}" >> Renviron

# rm Renviron.site 

# RDscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     
[3] "/usr/lib/R/library"           

# RDscript --vanilla -e "library(MASS)"
[No output]

It also works if you set R_LIBS_SITE instead of R_LIBS in Renviron, though I think that R_LIBS makes more sense.

install.r, install2.r etc do not fail when a package fails to install

This results in images building successfully (and thus displacing the previous image on the hub) even when certain intended packages cannot be installed.

Perhaps this should be filed as a littler issue(?), but I wanted to note the resulting problem here.

Set default CRAN mirror?

It would be useful if the R-base dockerfile set the default CRAN repo.

Beginner documentation?

I'm looking for some "beginner" documentation. It took me about three hours on the Docker hub to figure out that I needed to do

sudo docker pull rocker/rstudio

and I'm totally clueless what I need to do next if, say, I want to start up the RStudio Server on my workstation, browse to it and start working.

Is there such a document? I can at least contribute the Fedora 21 hosting part. ;-)

Containers for older versions of R

Would be useful to have some containers locked to specific versions, 3.0.2, 3.1.1 etc

Need to open port when starting boot2docker to enable rocker/rstudio on windows

Using Windows 7 I've found that I can only get the rocker/rstudio container to be accessible in my browser if I start boot2docker with:

boot2docker ssh -L 8787:localhost:8787 

and then

sudo docker run -d -p 8787:8787 rocker/rstudio

and then go to http://localhost:8787/ to access RStudio.

Starting docker directly from the boot2docker never manages to open the port. Happy to add this to your wiki if that's helpful.

Leftover files in /tmp

There's about 50MB of files in /tmp in the hadleyverse image:

# docker run --rm -ti eddelbuettel/ubuntu-hadleyverse du /tmp
50204   /tmp/downloaded_packages
4   /tmp/hsperfdata_root
50404   /tmp

Create docker-hub account for automated builds

Did we settle on how to go about this / what to call the docker hub account?

delete old cran mirror lists?

I thought we fixed this, but if I run, say, rocker/ropensci I see:

root@922311d39f4d:/#  ls -l /tmp/*rds
-rw-r--r-- 1 root root   1088 Nov  6 22:39 /tmp/libloc_169_8f48fc7d1db1bb3e.rds
-rw-r--r-- 1 root root    639 Nov  6 22:39 /tmp/libloc_174_173b0d0583319ed2.rds
-rw-r--r-- 1 root root   4489 Nov  6 23:09 /tmp/libloc_180_a38f7d5813344af9.rds
-rw-r--r-- 1 root root  55901 Nov  6 22:39 /tmp/repos_http%3a%2f%2fbioconductor.org%2fpackages%2f2.13%2fbioc%2fsrc%2fcontrib.rds
-rw-r--r-- 1 root root 186128 Nov  6 22:40 /tmp/repos_http%3a%2f%2fcran.rstudio.com%2fsrc%2fcontrib.rds
-rw-r--r-- 1 root root   2593 Nov  6 23:00 /tmp/repos_http%3a%2f%2fwww.omegahat.org%2fR%2fsrc%2fcontrib.rds
root@922311d39f4d:/# 

Note the outdated rds lists from the mirror. As a result, docker build on that Dockerfile fails right now, since some of the packages have been updated since Nov 6 and thus the versions listed in these rds files result in 404 errors...

wiki page for shared volumes

@benmarwick I created a wiki page to explicitly deal with shared volumes (since first-time users might find it less intimidating just to ignore volume sharing I thought this would be it's own section). Would appreciate your feedback:

https://github.com/rocker-org/rocker/wiki/Shared-files-with-host-machine

I've mostly focused on the Linux issues in sharing volumes in a way that doesn't mess with your file permissions. The docs on sharing on Mac and windows are pretty slim (given my inability to test them), but thought you might want to add a few notes here.

One reason I'd like to see sharing with the host machine become easier is that it means a user can still use native tools for text editing, finder/browser/explorer for file management, etc, while still benefiting from code execution in a standardized container-like environment. Curious what you're experience says on that front too; given that we can do all these things in RStudio anyway perhaps it's better pedagogy to stick to doing all this through RStudio anyway?

apt-get clean and other strategies for keeping image size small?

Should we be using apt-get clean in the RUN lines that call apt-get update && apt-get install to avoid unnecessary image space? not sure how large those files are.

Alias Rdevel(script) as RD(script) too?

I think i saw that somewhere in a Dockerfile or shell script by @wch (which seemed to build on my old shell script to build R-devel) that R-devel was linked to /usr/local/bin/RD. I kinda like that.

Any votes in favor? Or against?

Create the 3 base images in both ubuntu and debian flavors

Now that we've spelled out our objectives in #1, thought I would re-factor the action items into their own issues. First task is getting our base images in place:

	Ubuntu Dockerfile?	Debian Dockerfile?	Ubuntu Hub builds?	Debian Hub builds?
r-base	X	X		X
r-devel	X	X		X
rstudio	X*	X*		X

* pending updated FROM line to appropriate image on hub, see #3

Change the default branch (either on Hub or Github)?

It's a bit of a nuisance not to be able to tweak things like the README that folks see when landing on the Github page without triggering the build chain (which I've linked to the master branch Dockerfiles). Maybe we should just make the sandbox branch the 'default' for Github (Under repo settings; I assume that will make https://github.com/rocker-org/rocker open up on the sandbox branch, but haven't done that before)

image testing?

Wonder if it would be reasonable to run any tests on the packages of a given image? To test this out I've tried running:

 docker run --rm -it -v $(pwd):/host eddelbuettel/debian-r-base r -e 'sapply(installed.packages()[,"Package"], tools::testInstalledPackage, outDir="/host")'

Seems to work as a reasonable way to test the packages installed in debian-r-base (e.g. the base R packages).

suggestion box: private package repository container

Just an idea for the backlog, but a container for creating personal package repositories could be very useful.

move ropensci image from rocker repo?

@eddelbuettel Taking a quick look at updating the README and feeling like the ropensci repo doesn't fit as nicely within our scope as the other projects do. Thinking about making it's permanent home be https://github.com/ropensci/docker and http://hub.docker.com/ropensci/ropensci instead. (Could alternatively be just a new repo in rocker-org, I've no opinion either way). yay/nay?

I think our other 5 images fit much better into the core rocker scope as things other people would build upon.

R and Rdevel share some libpaths

Here are the libpaths for each:

$ docker run rocker/r-devel Rscript -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"      
[3] "/usr/lib/R/library"           

$ docker run rocker/r-devel Rscriptdevel -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     
[3] "/usr/lib/R/library"           

This causes problems when you install packages with Rdevel and then load them with R (and possibly vice versa).

$ docker run --rm -ti rocker/r-devel /bin/bash

# Rscriptdevel -e "install.packages('bitops', repos='http://cran.rstudio.com')"

root@f99ce81d4c09:/# Rscript -e "library(bitops)"
Warning message:
package ‘bitops’ was built under R version 3.2.0 

root@f99ce81d4c09:/# Rscript -e "packageDescription('bitops')"
Package: bitops
Version: 1.0-6
Date: 2013-08-17
Author: S original by Steve Dutky <[email protected]> initial R
        port and extensions by Martin Maechler; revised and modified by
        Steve Dutky
Maintainer: Martin Maechler <[email protected]>
Title: Bitwise Operations
Description: Functions for bitwise operations on integer vectors.
License: GPL (>= 2)
Packaged: 2013-08-17 15:58:57 UTC; maechler
NeedsCompilation: yes
Repository: CRAN
Date/Publication: 2013-08-17 21:10:34
Built: R 3.2.0; x86_64-unknown-linux-gnu; 2014-10-24 00:29:31 UTC; unix

-- File: /usr/local/lib/R/site-library/bitops/Meta/package.rds 

There are a total of 4 different directories. After running the commands above, here are the contents of each:

root@f99ce81d4c09:/# ls /usr/lib/R/site-library/
root@f99ce81d4c09:/# ls /usr/local/lib/R/site-library/
bitops  docopt  stringr
root@f99ce81d4c09:/# ls /usr/lib/R/library/
base   cluster    datasets  grDevices   lattice  methods  nnet      spatial  stats4    tools
boot   codetools  foreign   grid    MASS     mgcv     parallel  splines  survival  translations
class  compiler   graphics  KernSmooth  Matrix   nlme     rpart     stats    tcltk     utils
root@f99ce81d4c09:/# ls /usr/local/lib/R/library/
base  compiler  datasets  graphics  grDevices  grid  methods  parallel  splines  stats  stats4  tcltk  tools  translations  utils

Here's what it looks like each one of these is used for:

• /usr/local/lib/R/site-library/: Packages installed by root in both R and Rdevel.
• /usr/lib/R/site-library/: R has this in its libpath, but nothing seems to be there. This seems to serve no purpose, though I could be wrong.
• /usr/lib/R/library/: base packages for R, and packages installed via .debs, like r-cran-mass. This directory is also in Rdevel's libpath.
• /usr/local/lib/R/library/: base packages for Rdevel.

I assume that the libpaths for R are OK, since it seems to be the system default. Then the problems for Rdevel's libpath, c("/usr/local/lib/R/site-library", "/usr/local/lib/R/library", "/usr/lib/R/library"), are:

• /usr/local/lib/R/site-library is shared with R.
• /usr/lib/R/library contains the base packages for R 3.1, but Rdevel is version 3.2. However, most, but not all of the packages in this directory are masked by /usr/local/lib/R/library.

Here are couple options:

• Set the libpath for Rdevel to just /usr/local/lib/R/library
• Set the libpath for Rdevel to /usr/local/lib/R/site-library-devel, /usr/local/lib/R/library. You'd need to create the site-library-devel directory.

How about a shiny image

I find myself configuring yet another computer to run Shiny server, and thought docker would be great for this. My idea for the dockerfile would be to start from r-base, then install packrat, shiny, and shiny-server. Then use the ONBUILD directive in the Dockerfile to ADD any packrat information, update packages, ADD a local directory and shiny-server.conf, open up port 3838, and run shiny-server.

The advantage of the weird ONBUILD is that a user does not need to know much about docker: they simply set up the packrat config, the directory of shiny code, and the shiny-server.conf, and can use a one line Dockerfile .

I can probably throw this together quickly..

linking containers to provide TeX?

Been thinking about this for a while, but @benmarwick 's examples with --volumes-from convinced me to give this a try.

While there's an obvious level of convenience in having something like LaTeX bundled into the hadleyverse container so that users can build nice pdfs, if often feels not very docker-esque to me to just throw the kitchen sink into a container. At the risk of some added complexity, we can provide LaTeX from a dedicated TeX container to a container that doesn't have it built in, like rocker/rstudio. Check this out:

docker run --name tex -v /usr/local/texlive texlive
docker run -dP --volumes-from tex \
  -e PATH=$PATH:/usr/local/texlive/2014/bin/x86_64-linux/ \
    rocker/rstudio 

We can now log into RStudio, create a new Rnw file and presto, RStudio discovers the tex compilers and builds us a pdf. This does make our Docker execution lines a bit long, but that's what fig is for. (Or a good ole Makefile).

The above example uses a version I built locally on a debian:testing container, for a whopping 4 GB container; of course the LaTeX in hadleyverse is stripped down to about a 1GB install. Looks like one can also just use this existing docker image from the hub: https://registry.hub.docker.com/u/leodido/texlive/dockerfile/ (even though it's built on centos?)

Note this requires we build texlive in a way that isolates it to it's own path (e.g. /usr/local/texlive). The default installation with apt-get installs everything in separate locations that overlap with existing directories (like /usr/bin), which makes linking clumsy or impossible (we would need separate paths for all the components, e.g. since shared libraries aren't found under the bin path, and we cannot link such a volume to another container without destroying everything in it's /usr/bin, clearly not a good idea). Instead, if we use the standard texlive install script from https://www.tug.org/texlive/, this installs everything into /usr/local/texlive which is much more portable as illustrated above. Not quite sure if it's actually a good idea to build containers this way or not.

unable to install seqinr

docker run -t rocker/r-base Rscript -e 'install.packages("seqinr")'
...
** R
Warning in parse(outFile) :
  invalid input found on input connection '/usr/local/lib/R/site-library/seqinr/R/seqinr'
Error in parse(outFile) : 
  /tmp/RtmpCwXuIp/R.INSTALL1a409031a/seqinr/R/synonymous.R:69:0: unexpected end of input
67:     })
68:     usage = uco(sequence)[allcodons] #r
   ^
ERROR: unable to collate and parse R files for package ‘seqinr’
* removing ‘/usr/local/lib/R/site-library/seqinr’

The downloaded source packages are in
    ‘/tmp/RtmpitkBKh/downloaded_packages’
Warning message:
In install.packages("seqinr") :
  installation of package ‘seqinr’ had non-zero exit status

This seems to be an encoding issue, there's a french accent at seqinr/R/synonymous.R:69:0.
But I wonder: could we not just set the same setting than the CRAN check process ?

Thanks.

access files on OS X and how to extend existing images

First of all MANY THANKS for this great effort: you are rocking the R world!
My questions:
I went through the wiki (and the linked page) but I am still unable to see my OS X files. Would you be so kind to add a full example?

I would like to use rocker for my team (it is actually a godsend!), which means that I would like to create a version with more packages (suitable for my project).
How to extend the existing images?
I also would like to create a shiny server image (unless the guys at rstudio are planning to do that).
Thanks again

Create / convert Hub accout to an organization?

Looks like the Docker Hub now supports organizations: https://hub.docker.com/account/organizations/
Don't recall that being there last I checked. Do you think it would make sense to convert or migrate eddelbuettel rocker repositories to a "rocker" organization? Seems like it would get around the limitations we were having with the collaborators configuration in the current setup.

If we do move to an organization, we might want to decide on the 2 flavors or not-2-flavors issue at the same time (just making all images debian based), so we have fewer namespace changes (e.g. go from the verbose to the compact: eddelbuettel/debian-rstudio -> rocker/rstudio in one go).

rocker/rstudio login authentication

Perhaps related to this commit and #63, but setting username and password such as
docker run -d -p 8787:8787 -e USER:goodusername -e PASSWORD:goodpassword rocker/rstudio
does not result in login with the specified usr/pass, but instead defaults to usr/pass of rstudio/rstudio.

Default CRAN repo for R-devel

Right now, there's no default CRAN repo for R-devel. So this happens:

$ docker run rocker/r-devel Rscriptdevel -e "install.packages('digest')"
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
Error in contrib.url(repos, type) : 
  trying to use CRAN without setting a mirror
Calls: install.packages -> grep -> contrib.url
Execution halted

Adding this to the Dockerfile should fix it:

RUN echo 'options("repos"="http://cran.rstudio.com")' >> /usr/local/lib/R/etc/Rprofile.site

Deprecate eddelbuettel/docker-ubuntu-r repos?

How do we want to go about this? Currently I've copied the dockerfiles over from those repos to their respective locations in r-base and and r-devel in this repo. (Not sure if r-devel should be one the sann flavor or just the plain r-devel flavor, but you can pick there).

The rstudio base images still declare the docker-ubuntu-r/docker-debian-r in their FROM line, but I assume we eventually want them to use the images from the rocker repo and deprecate the other repos?

Old README in need of an update?

https://github.com/rocker-org/rocker/blob/master/debian/rstudio/README.md still refers to the old repo etc pp.

Should the content be in the wiki instead?

We generally need to update / fill-in a few of the README.md files.

Think it would be possible to get an official R stack?

e.g. see http://blog.docker.com/2014/09/docker-hub-official-repos-announcing-language-stacks/

Tickle builds via POST request?

The build trigger page(s) look like they would offer finer control than the unconditional 'build when commit made'.

An open question is how to learn about success/failure of dependencies.

usecase: Hadleyverse

A use case image that builds on the ubuntu/rstudio image ¹, adding the popular suite of packages from Hadley, along with the dependencies to make them most useful.

Questions:

• Does this image include the RStudio packages like rmarkdown & knitr, (and hence pandoc, maybe some tex?) or is that a separate use-case?
• Similarly, does this image include all the LaTeX libraries needed for generating pdfs (e.g. with rmarkdown). Presumably basic Sweave users would have enough LaTeX libraries in r-devel, but the default pandoc templates use more.

My intuition for now is yes, put all of these in. I hesitate because an even semi-comprehensive LaTeX suite dwarfs everything else combined, at least 2 gigs (texlive-full is 3324 MB installed).

• Do we stick with CRAN versions? I'll probably include a few github installs for cases where the CRAN version carries bugs that are fixed in packages that are rather stable on github (e.g. reshape2)

Footnotes

1. My intuition is not to necessarily build both debian and ubuntu versions for all the usecases, but just for the base images, since base images are meant to be general purpose, but each use-case image is supposed to be more targeted by demand or something like that. ↩

Problem with r-base or package "bit" ?

If I run:

docker run -ti rocker/r-base Rscript -e 'install.packages("bit")'

I get a lot of warnings:

* installing *source* package ‘bit’ ...
** package ‘bit’ successfully unpacked and MD5 sums checked
Warning in writeLines(paste0(c(out[is_not_empty]), eor), file) :
  invalid char string in output conversion
Warning in writeLines(paste0(c(out[is_not_empty]), eor), file) :
  invalid char string in output conversion
** libs
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG      -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c attrutil.c -o attrutil.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG      -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c bit.c -o bit.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG      -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c chunkutil.c -o chunkutil.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG      -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c clone.c -o clone.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG      -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c rle.c -o rle.o
gcc -std=gnu99 -shared -Wl,-z,relro -o bit.so attrutil.o bit.o chunkutil.o clone.o rle.o -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/bit/libs
** R
Warning in readLines(f, warn = FALSE) :
  invalid input found on input connection '/tmp/RtmpFI8WH0/R.INSTALL1441396420/bit/R/attrutil.R'
Warning in readLines(f, warn = FALSE) :
  invalid input found on input connection '/tmp/RtmpFI8WH0/R.INSTALL1441396420/bit/R/bit.R'
...


Warning message:
In install.packages("bit") :
  installation of package ‘bit’ had non-zero exit status

I guess it is related to encodings. I got the same issue with my own docker.
Any idea ?

P.S
My own normal R-3.1.1 manually compiled on my ubuntu does not this issue

Thanks

Miscellaneous things that would be useful

Glad you guys are working on this! Sorry to file this as a single issue, but I figured it would be less annoying than filing them as separate issues, at least for now.

Here are some things that would be useful -- for my use cases, at least:

• Nightly builds of an r-devel image
• Images for package development, checking, and building, which include latex (I suppose instaling tetex should happen early on in the docker file, before installing things like RStudio and R-devel, which change frequently)
• It would also be handy to have a way to log into a running container, because sometimes you need to poke around. (Though maybe this isn't necessary, because it sounds like nsenter is the way to go in the future.)