knitr::opts_chunk$set(collapse = TRUE, comment = "#>")
GRANBase is an open source set of tools for testing and deploying R
packages as package repositories for both general deployment and
result reproduction. It is based on the switchr
framework, and
allows users to deploy package manifests as validated repositories.It
is centered around the R repository mechanism for pacakge
distribution. GRANBase provides three major areas of functionality:
R
repositories by pulling and
testing packages from diverse locations (scm, local directory), in a
manner conducive to continuous integrationGRANBase relies on the GRANCore framework for repository management,
which in turn is based on package manifests (PkgManifest or
SeedingManifest objects from the switchr
framework).
Given a manifest, initial construction and rebuilding of individual
GRANBase repositories (referred to as subrepositories because
GRANBase supports a form of branched deployment) is performed via the
makeRepo
function. For example:
suppressPackageStartupMessages(library(GRANBase)) chooseCRANmirror(ind=1L) options(error=traceback)
testpkgs <- list.files(system.file("testpkgs", package = "GRANBase"), full.names = TRUE) man <- PkgManifest(name = basename(testpkgs), url = testpkgs, type = "local") repdir <- file.path(tempdir(), "repos") if(!file.exists(repdir)) dir.create(repdir) repo <- makeRepo(man, repo_name= "stable", basedir = repdir, destination = repdir, cores = 1L, install_test = TRUE, check_test = FALSE)
NOTE: In the above code, we disabled the installation and R CMD
check
-related tests due to not playing well with the CRAN build
system. In most cases, these should be TRUE
in order to create a
validated package repository. Also note that in the output below, the
willfail
package appears in the repository. This would not be the
case if the check test was turned on, as it is engineered as a test
case to fail check.
available.packages(repo, type="source")
Note that the repository contains the package GRANstable
. This was
generated automatically, and exports a defaultGRAN()
function which
the switchr
package will use when the package is loaded to
incorporate our package into the set of default repositories.
GRANBase represents (sub)repositories as GRANRepository
objects,
which come from the GRANCore
package. These objects contain all the
information required to build and deploy the repository.
Once a repository is created, its GRANRepository
object is saved
within the created directory structure as the repo.R
file. This
allows future builds to be invoked by the simpler syntax of passing a
GRANRepository
object or path to a created repository to
makeRepo()
directly:
repo <- makeRepo(file.path(repdir, "stable"), cores=1L)
The makeRepo()
function also accepts a build_pkgs
argument, which
will cause only the specified packages (and their reverse
dependencies) to be rebuilt, regardless of changes in version number.
repo2 <- makeRepo(repo, build_pkgs = basename(testpkgs)[1], cores = 1L)
GRANBase performs the following steps when creating or updating a repository. At the end of each step, the packages' statuses are updated to reflect the results of that step.
R CMD build
.CRAN
, and Bioconductor
-based dependencies, are installed into a temporary library location.R CMD CHECK
, and their statuses are updated accordinglyCHECK
warnings and notes can be all owed, or not) are deployed into the final destination repositoryGRANRepository
object are savedGRANRepsitory
object is returnedIn order to get a clean slate we can clear the repository, which will empty it completely (optionally excluding the code checkouts) via clear\_repo
or we can clear just temporary files without wiping the recorded results with clear\_temp\_files
.
repo2 <- clear_temp_files(repo, checkout = FALSE, logs = FALSE) repo2 <- clear_repo(repo2, checkout = TRUE) repo_results(repo2)
We can then build the repo again using the expected machinery.
repo3 <- makeRepo(repo, install_test = FALSE, check_test = FALSE)
GRANBase also provides tools to navigate the tension between stability and using the most up-to-date version of packages to have the latest bug fixes available.
The identifyRisk
function identifies which currently installed
packages can be updated, and determines the packages that could
possibly be affected by updating the package. In particular, the
function allows the user to identify a vector of important packages
and assesses the risks to each of them (by default, it takes that to
be the full set of installed packages).
Risk here has a dual meaning. On the one hand updating a package which an important package depends on incurs the risk of changing the important package's behavior, potentially changing results in a critical application. On the other hand, not updating a such a package may leave important bug fixes un-applied, drawing the results generated when using the important package into question.
buildRiskReport
builds an HTML report which lists information about
each package with an update available in an easy to digest table. It
also provides a list of specific risks to each important package
(packages with no risks identified are currently omitted).
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.