A new package has hit the CRAN shelves this week. While
knitr is one of the most useful R packages in existence,
ezknitr is a simple extension to it that adds flexibility in several ways.
One common source of frustration with
knitr is that it assumes the directory where the source file lives should be the working directory, which is often not true.
ezknitr addresses this problem by giving you complete control over where all the inputs and outputs are, and adds several other convenient features. The two main functions are
ezspin(), which are wrappers around
spin(), used to make rendering markdown/HTML documents easier.
Table of contents
- Motivation & simple use case
- Use case: using one script to analyze multiple datasets
- Experiment with ezknitr
- spin() vs knit()
- Using rmarkdown::render()
If you have a very simple project with a flat directory structure, then
knitr works great. But even something as simple as trying to knit a document that reads a file from a different directory or placing the output rendered files in a different folder cannot be easily done with
ezknitr improves basic
knitr functionality in a few ways. You get to decide:
- What the working directory of the source file is
- Default is your current working directory, which often makes more sense than the
knitrassumption that the working directory is wherever the input file is
- Default is your current working directory, which often makes more sense than the
- Where the output files will go
knitr, all the rendered output files will be generated in the folder you’re currently in
- Where the figures generated in the markdown document will be stored
knitrmakes it cumbersome to change this directory
- Any parameters to pass to the source file
- Useful if you want to run an identical source file multiple times with different parameters
Motivation & simple use case
Assume you have an Rmarkdown file that reads a data file and produces a short report while also generating a figure. Native
spin() if you’re starting with an R script instead of an Rmd file) works great if you have a flat directory structure like this:
- project/ |- input.csv |- report.Rmd
But what happens if you have a slightly more complex structure? In a real project, you rarely have everything just lying around in the same folder. Here is an example of a more realistic initial directory structure (assume the working directory is set to
- project/ |- analysis/ |- report.Rmd |- data/ |- input.csv
Now if you want
knitr to work, you’d have to ensure the path to
input.csv is relative to the
analysis/ directory. This is counter-intuitive because most people expect to create paths relative to the working directory (
project/ in this case), but
knitr will use the
analysis/ folder as the working directory. Any code reading the input file needs to use
../data/input.csv instead of
Other than being confusing, it also means that you cannot naively run the Rmd code chunks manually because when you run the code in the console, your working directory is not set to what
knitr will use as the working directory. More specifically, if you try to run the command that reads the input file, your console will look in
project/../data/input.csv (which doesn’t exist).
A similar problem arises when you want to create files in your report:
knitr will create the files relative to where the Rmd file is, rather than relative to the project root.
Another problem with the flat directory structure is that you may want to control where the resulting reports get generated.
knitr will create all the outputs in your working directory, and as far as I know there is no way to control that.
ezknitr addresses these issues, and more. It provides wrappers to
spin() that allow you to set the working directory for the input file, and also uses a more sensible default working directory: the current working directory.
ezknitr also lets you decide where the output files and output figures will be generated, and uses a better default path for the output files: the directory containing the input file.
Assuming your working directory is currently set to the
project/ directory, you could use the following
ezknitr command to do what you want:
1 library(ezknitr) 2 ezknit(file = "analysis/report.Rmd", out_dir = "reports", fig_dir = "myfigs")
- project/ |- analysis/ |- report.Rmd |- data/ |- input.csv |- reports/ |- myfigs/ |- fig1.png |- report.md |- report.HTML
We didn’t explicitly have to set the working direcory, but you can use the
wd argument if you do require a different directory. After running
ezknit(), you can run
open_output_dir() to open the output directory in your file browser if you want to easily see the resulting report. Getting a similar directory structure with
knitr is not simple, but with
ezknitr it’s trivial.
ezknitr produces both a markdown and an HTML file for each report (you can choose to discard them with the
Use case: using one script to analyze multiple datasets
As an example of a more complex realistic scenario where
ezknitr would be useful, imagine having multiple analysis scripts, with each one needing to be run on multiple datasets. Being the organizer scientist that you are, you want to be able to run each analysis on each dataset, and keep the results neatly organized. I personally was involved in a few projects requiring exactly this, and
ezknitr was in fact born for solving this exact issue. Assume you have the following files in your project:
- project/ |- analysis/ |- calculate.Rmd |- explore.Rmd |- data/ |- human.dat |- mouse.dat
We can easily use
ezknitr to run any of the analysis Rmarkdowns on any of the datasets and assign the results to a unique output. Let’s assume that each analysis script expects there to be a variable named
DATASET_NAME that tells the script what data to operate on. The following
ezknitr code illustrates how to achieve the desired output.
1 library(ezknitr) 2 ezknit(file = "analysis/explore.Rmd", out_dir = "reports/human", 3 params = list("DATASET_NAME" = "human.dat"), keep_html = FALSE) 4 ezknit(file = "analysis/explore.Rmd", out_dir = "reports/mouse", 5 params = list("DATASET_NAME" = "mouse.dat"), keep_html = FALSE) 6 ezknit(file = "analysis/calculate.Rmd", out_dir = "reports/mouse", 7 params = list("DATASET_NAME" = "mouse.dat"), keep_html = FALSE)
- project/ |- analysis/ |- calculate.Rmd |- explore.Rmd |- data/ |- human.dat |- mouse.dat |- reports/ |- human/ |- explore.md |- mouse/ |- calculate.md |- explore.md
Note that this example uses the
params = list() argument, which lets you pass variables to the input Rmarkdown. In this case, I use it to tell the Rmarkdown what dataset to use, and the Rmarkdown assumes a
DATASET_NAME variable exists. This of course means that the analysis script has an external dependency by having a variable that is not defined inside of it. You can use the
set_default_params() function inside the Rmarkdown to ensure the variable uses a default value if none was provided.
Also note that differentiating the species in the output could also have been done using the
out_suffix argument instead of the
out_dir argument. For example, using
out_suffix = "human" would have resulted in an ouput file named
Experiment with ezknitr
After installing the package, you can experiment with
ezknitr using the
setup_ezspin_test() functions to see their benefits. See
?setup_ezknit_test for more information.
spin() vs knit()
knit() is the most popular and well-known function from
knitr. It lets you create a markdown document from an Rmarkdown file. I assume if you are on this page, you are familiar with
knit() and Rmarkdown, so I won’t explain it any further.
spin() is similar, but starts one step further back: it takes an R script as input, creates an Rmarkdown document from the R script, and then proceeds to create a markdown document from it.
spin() can be useful in situations where you develop a large R script and want to be able to produce reports from it directly instead of having to copy chunks into a separate Rmarkdown file. You can read more about why I like
spin() in the blog post “knitr’s best hidden gem: spin”.
When the core of this package was developed, none of its functionality was supported in any way by either
rmarkdown. Over time,
rmarkdown::render() got some new features that are very similar to features of
ezknitr. Native support for parameters inside Rmarkdown files using YAML is a big feature which makes the use of
set_default_params() and the
params argument of
ezknitr less important. However, the core problem that
ezknitr wants to solve is the working directory issue, and this issue has yet to be addressed by
knitr, which makes
ezknitr still useful.