Chapter 2 Similar work
drake
enhances reproducibility and high-performance computing, but not in all respects. Literate programming, local library managers, containerization, and strict session managers offer more robust solutions in their respective domains. And for the problems drake
does solve, it stands on the shoulders of the giants that came before.
2.1 Pipeline tools
2.1.1 GNU Make
The original idea of a time-saving reproducible build system extends back at least as far as GNU Make, which still aids the work of data scientists as well as the original user base of compiled language programmers. In fact, the name “drake” stands for “Data Frames in R for Make”. Make is used widely in reproducible research. Below are some examples from Karl Broman’s website.
- Bostock, Mike (2013). “A map of flowlines from NHDPlus.” https://github.com/mbostock/us-rivers. Powered by the Makefile at https://github.com/mbostock/us-rivers/blob/master/Makefile.
- Broman, Karl W (2012). “Halotype Probabilities in Advanced Intercross Populations.” G3 2(2), 199-202.Powered by the
Makefile
at https://github.com/kbroman/ailProbPaper/blob/master/Makefile. - Broman, Karl W (2012). “Genotype Probabilities at Intermediate Generations in the Construction of Recombinant Inbred Lines.” *Genetics 190(2), 403-412. Powered by the Makefile at https://github.com/kbroman/preCCProbPaper/blob/master/Makefile.
- Broman, Karl W and Kim, Sungjin and Sen, Saunak and Ane, Cecile and Payseur, Bret A (2012). “Mapping Quantitative Trait Loci onto a Phylogenetic Tree.” Genetics 192(2), 267-279. Powered by the
Makefile
at https://github.com/kbroman/phyloQTLpaper/blob/master/Makefile.
Whereas GNU Make is language-agnostic, drake
is fundamentally designed for R.
- Instead of a Makefile,
drake
supports an R-friendly domain-specific language for declaring targets. - Targets in GNU Make are files, whereas targets in
drake
are arbitrary variables in memory. (drake
does have opt-in support for files viafile_out()
,file_in()
, andknitr_in()
.)drake
caches these objects in its own storage system so R users rarely have to think about output files.
2.1.2 Remake
remake itself is no longer maintained, but its founding design goals and principles live on through drake. In fact, drake is a direct reimagining of remake with enhanced scalability, reproducibility, high-performance computing, visualization, and documentation.
2.1.3 Factual’s Drake
Factual’s Drake is similar in concept, but the development effort is completely unrelated to the drake R package.
2.1.4 Other pipeline tools
There are countless other successful pipeline toolkits. The drake
package distinguishes itself with its R-focused approach, Tidyverse-friendly interface, and a thorough selection of parallel computing technologies and scheduling algorithms.
2.2 Memoization
Memoization is the strategic caching of the return values of functions. It is a lightweight approach to the core problem that drake
and other pipeline tools are trying to solve. Every time a memoized function is called with a new set of arguments, the return value is saved for future use. Later, whenever the same function is called with the same arguments, the previous return value is salvaged, and the function call is skipped to save time. The memoise
package is the primary implementation of memoization in R.
Memoization saves time for small projects, but it arguably does not go far enough for large reproducible pipelines. In reality, the return value of a function depends not only on the function body and the arguments, but also on any nested functions and global variables, the dependencies of those dependencies, and so on upstream. drake
tracks this deeper context, while memoise does not.
2.3 Literate programming
Literate programming is the practice of narrating code in plain vernacular. The goal is to communicate the research process clearly, transparently, and reproducibly. Whereas commented code is still mostly code, literate knitr / R Markdown reports can become websites, presentation slides, lecture notes, serious scientific manuscripts, and even books.
2.3.1 knitr and R Markdown
drake
and knitr are symbiotic. drake
’s job is to manage large computation and orchestrate the demanding tasks of a complex data analysis pipeline. knitr’s job is to communicate those expensive results after drake
computes them. knitr / R Markdown reports are small pieces of an overarching drake
pipeline. They should focus on communication, and they should do as little computation as possible.
To insert a knitr report in a drake
pipeline, use the knitr_in()
function inside your drake
plan, and use loadd()
and readd()
to refer to targets in the report itself. See an example here.
2.3.2 Version control
drake
is not a version control tool. However, it is fully compatible with git
, svn
, and similar software. In fact, it is good practice to use git
alongside drake
for reproducible workflows.
However, data poses a challenge. The datasets created by make()
can get large and numerous, and it is not recommended to put the .drake/
cache or the .drake_history/
logs under version control. Instead, it is recommended to use a data storage solution such as DropBox or OSF.
2.3.3 Containerization and R package environments
drake
does not track R packages or system dependencies for changes. Instead, it defers to tools like Docker, Singularity, renv
, and packrat
, which create self-contained portable environments to reproducibly isolate and ship data analysis projects. drake
is fully compatible with these tools.
2.3.4 workflowr
The workflowr
package is a project manager that focuses on literate programming, sharing over the web, file organization, and version control. Its brand of reproducibility is all about transparency, communication, and discoverability. For an example of workflowr
and drake
working together, see this machine learning project by Patrick Schratz (source).
2.4 Acknowledgements
Special thanks to Jarad Niemi, my advisor from graduate school, for first introducing me to the idea of Makefiles for research. He originally set me down the path that led to drake
.
Many thanks to Julia Lowndes, Ben Marwick, and Peter Slaughter for reviewing drake for rOpenSci, and to Maëlle Salmon for such active involvement as the editor. Thanks also to the following people for contributing early in development.
- Alex Axthelm
- Chan-Yub Park
- Daniel Falster
- Eric Nantz
- Henrik Bengtsson
- Ian Watson
- Jasper Clarkberg
- Kendon Bell
- Kirill Müller
Credit for images is attributed here.