I’m still experimenting with these approaches myself, so feedback would be great as to what makes sense and what seems too complex or fragile in this approach.

This just runs the Docker image on the Binder platform and drops you into a familiar RStudio setting. In some sense this is the most comprehensive, since it includes ‘hardware’ as well as the runtime environment, but should also be the least friction in that it doesn’t require anything to “install”, just click the “Binder” button. Layer 4 is perhaps binder runtime environment. Short-term this is probably too much of a nuisance for most users who won’t have Docker installed, but long-term this should be an easier way to manage dependencies than packrat. rocker/binder:3.4.4 or the latest environment, for comparison. This layer should be easy to deploy either in a version stable environment (e.g. This should provide a stable, complete environment, along with system dependencies. install_github('cboettig/noise-phenomena', dep=TRUE) will try to install these as well, but note that some system dependencies (just fonts, in this case) are required for these so I thought it helpful to make them “soft dependencies”. the code should run without them, you’ll just get different fonts. Note that dependencies used only for formatting-related niceties ( extrafont, hrbrthemes are listed as “Suggests” and not installed by default. Layer 2 is the R package: you can install the compendium locally using install_github(), this will grab dependencies automatically. In principle, most readers familiar with R can probably just copy-paste code out of the Rmd appendix successfully with no concern about versions. To grab a concrete example, I’ve tried to do this here. I see the additional layers as “fall back” options, which can be useful down the road as software changes. I really like Noam’s notion of layered reproducibility. Of course something could happen to MRAN or Rocker or another upstream dependency that would prevent building this environment, so as a third layer, one can store the binary of the build in your repository, as well.Įach successive layer is slightly more involved to use, and less easy to incorporate into other work, but more likely to be reproducible in the future. With Rocker docker images with fixed R versions, MRAN is used as the CRAN mirror with a fixed date, which should ensure that the same versions of packages always install. This has the advantage of being easy to deploy on a lot of services, too. So I prefer to also have Dockerfile a creates the environment, based on a Rocker image. This has its limits, as you mention above. Making an R package is a very good way of wrapping up the pieces of the package for re-use, with dependencies specified in the DESCRIPTION. That said, I try to aim for layered reproducibility, such that you maximized the reproducibility of the project within successive tools.

I’d say using Docker or a similar environment is the best approach, especially if you have external system dependencies. Is there a way to create a package to always reproduce a paper exactly, or is the answer to use Docker? Since R can’t have multiple versions of the same package loaded at the same time, specifying an exact dependency dramatically increases the chance of conflicting versions.įollowing this advice ( MASS (>= 7.3.0)), it seems possible that a future user could use a different version and potentially encounter broken code or obtain different results. You almost always want to specify a minimum version rather than an exact version ( MASS (= 7.3.0)). In his book “R Packages”, Hadley has the following advice: Specifically, I’m looking for advice on external dependencies. I’m wondering how to create a package for maximum reproducibility. In many ways, the easiest option I’ve found is to create a Docker image file that will fully re-create the environment for reproducing the paper.īut I’m also intrigued by the idea of creating a package for the paper. I’ve tried using packrat in the past, but I just could not seem to get it to work right.

My objective is to share a fully reproducible analysis that will allow anyone to generate our pre-print.

Packrat r on jupyter notebook