R packages available via the CRAN mirror network system are of consistently high quality and tend to “Just Work”. One of the many reasons for this is a good culture of “do not break other packages” which is controlled for / enacted by the CRAN maintainers. Package maintainers are expected to do their part—by checking their packages!
To take one example, Rcpp is package with a pretty large tail of dependencies: as of this writing in late 2017, about 1270 other packages use it. So 1270 other packages need to be tested. This takes time, especially when running serially. But it is easy to parallelise.
Previously, a few ad-hoc scripts (available here) were used for a number of packages. The scripts were one-offs and did their job. But with the idea of running jobs in parallel, the liteq package by Gabor Csardi fit the requirements nicely.
The first operation is to enqueue jobs. In the simplest form
we do (assuming the included script is in the PATH)
$ enqueueJobs -q queueDirectory RcppThe same operation can also be done from R itself, see
help(enqueueJobs). A package name has to be supplied; a
directory name (for the queue directory) is optional. This function uses
two base R functions to get all available packages and then determine
the (non-recursive, first-level) reverse dependencies of the given
package. These are then added to the queue as “jobs”.
This is the second operation, and it can be done in parallel. In other words, in several shells do:
$ dequeueJobs -q queueDirectory Rcppwhich will find the (current) queue file in the specified directory
for the given package—here Rcpp. Again, this can also be
done from an R prompt if prefered, see
help(dequeueJobs).
Each worker, when idle, goes to the queue and requests a job, which it then labors over by testing the thus-given reverse depedency. Once done, the worker is idle and returns to the queue and the cycle repeats.
As there is absolutely no interdepedence between the tests, this parallelises easily up to the resource level of the machine.
To illustrate, “wall time” for a reverse-dependecy check of Rcpp decreased
from 14.91 hours to 3.75 hours (or almost four-fold) using six workers.
An earlier run of RcppArmadillo
decreased from 5.87 hours to 1.92 hours (or just over three-fold) using
four workers, and to 1.29 hours (or by 4.5) using six workers (and a
fresh ccache, see here for its
impact). In all cases the machine which was used was generally not
idle.
The following screenshot shows a run for RcppArmadillo with six workers. It shows the successes in green, skipped jobs in blue (from packages which sometimes would result in runaway tests), and no failures (which would be shown in red).
The split screen and additional tables are thanks to the wonderful byobu wrapper around tmux.
The scripts use an internal YAML file access via the config package by
JJ. The following locations are searched: .prrd.yaml,
~/.R/prrd.yaml, ~/.prrd.yaml, and
/etc/R/prrd.yaml. For my initial tests I used these
values:
## config for prrd package
default:
setup: "~/git/prrd/local/setup.R"
workdir: "/tmp/prrd"
libdir: "/tmp/prrd/lib"
debug: "false"
verbose: "false"The workdir and libdir variables specify
where tests are run and which additonal library directory is used. A
more interesting variable is setup, which points to a
helper script which gets sourced. This permits setting of the CRAN repo
address and any additonal environment variables needed for tests. My
current script is in
the repository.
While the package is new, it has already been used for a few complete reverse depends tests runs.
The package is now on CRAN and can be installed via a standard
install.packages("prrd")Dirk Eddelbuettel
GPL (>= 2)