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?
#PACKRAT R ON JUPYTER CODE#
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.
#PACKRAT R ON JUPYTER HOW TO#
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.
0 kommentar(er)
