Creating a package to reproduce an academic paper

General Q&A
21

Now, that I finally got around writing my Dockerfile, I got confused again about how to correctly apply your advice.

I had originally understood you in the following way:

  1. already installed packages that are bundled with the rocker container are fixed by the version I specify in FROM rocker/xxx:{version}.
  2. all packages I install using my custom Dockerfile, ARE NOT FIXED by that version/date and have to be fixed by providing a specific MRAN snapshot.

If I understand this correctly, it says that 2 isn’t the case, and all packages one installs later on ARE FIXED to the MRAN date of the container version and one would only have to fix the MRAN snapshot if one wants an earlier one. Could you please explain what of the two is correct?

Furthermore, if my first interpretation is correct and I have to fix the MRAN snapshot date, I don’t completely understand how to do that as I have seen different approaches online:

  1. You suggest:
ENV MRAN=https://mran.microsoft.com/snapshot/2018-07-01
RUN install2.r pkg1 pkg2
  1. In the rocker Dockerfiles: the following syntax is used:
&& MRAN=https://mran.microsoft.com/snapshot/${BUILD_DATE} \
  && echo MRAN=$MRAN >> /etc/environment \
  && export MRAN=$MRAN \
  && echo "options(repos = c(CRAN='$MRAN'), download.file.method = 'libcurl')" >> /usr/local/lib/R/etc/Rprofile.site \
  1. Furthermore, I have seen this approach:
  && R -e "options(repos='https://mran.microsoft.com/snapshot/2017-07-01'); devtools::install('/researchcompendium', dep=TRUE)" \

I like the simplicity of approach 3, i.e., listing all the dependencies of my analysis package in the DESCRIPTION file and having devtools install both the package and the dependencies in one command. I’m unsure about how to correctly fix the MRAN snapshot though.

Thank you so much for your help!

22

@januz sorry for the confusion! No need to supply a custom date to have a reproducible build.

If your version tag is something older than the latest release, e.g. 3.5.0, then your MRAN date is already locked to the last day 3.5.0 was current (i.e. 2018-07-02 in this case). If you chose 3.5.1, your MRAN date will move up every month until there’s a newer release, then it will freeze. (See versions.md for dates).

Of course, if you don’t want the date to be “the last day such-and-such R version was current”, you can set the MRAN date to whatever date you want, using whatever method you want. (I’m not sure the first option will work, you could instead do install2.r --repo https://mran.microsoft.com/snapshot/2017-07-01 pkg1 pkg2). I also like @benmarwick’s approach.

Only tags :latest and :devel don’t install packages from MRAN, these always pull the latest stuff from CRAN.

1 Like
23

@cboettig Thank you so much for clearing things up for me!

24

A bit late to the discussion, but isn’t CodeOcean aimed at doing this?