Temporarily ignore certain libraries in R - r

Question

I am currently working on a continuous integration setup for R packages developed by our company. We have one Jenkins project for each R package and a corresponding library for each project.
I already defined a logic that installs all dependencies of the package into the project library. Now i want to define a check stage which basically runs
devtools::check("${PROJECT_DIR}/pkg")
but only use the project library for dependencies. I tried to use the callr package in the following manner.
callr::r(
function(...) {
devtools::check(...)
),
args = list("${PROJECT_DIR}/pkg"),
libpath = "${PROJECT_DIR}/lib"
)
However, the check process is still able to find packages which are not installed in libpath. Is there a way to make sure that only "${PROJECT_DIR}/lib" is used during the build stage?
So far, I have tried the following to no avail
callr() with the libpath argument
withr::with_libpaths with the new argument
Look through the documentation in devtools::check and R CMD BUILD for
appropriate parameters
Use .libPaths("${JOB_DIR}/lib")
Here is a repex to explain the unexpected behavior of callr. I expect an error in line 3.
find.package("ggplot2", .libPaths()[1])
#> Error in find.package("ggplot2", .libPaths()[1]): there is no package called 'ggplot2'
callr::r(function() { ggplot2::vars() }, libpath = .libPaths()[1])
#> named list()
find.package("ggplot2", .libPaths()[2])
#> [1] "/data/R/3.5.3/lib/R/library/ggplot2"
callr::r(function() { ggplot2::vars() }, libpath = .libPaths()[2])
#> named list()

Answer 1

Accoding to this question there is a way to archieve this with base::assign. If there is a more proper solution, I would love to hear it.
callr::r(function() {
assign(".lib.loc", .libPaths()[1], envir = environment(.libPaths))
ggplot2::vars()
})
#> Error in loadNamespace(name): there is no package called ‘ggplot2’
The issues I have here are twofold
It is basically a hack and can break any time if the internals of .libPaths() change
I might have to modify .Library and .Library.site (internals of .libPaths()) as well in order to make sure that devtools::check is affected appropriately.

Answer 2

This might be slightly off topic, but have you considered using docker for this use case?
You can define a Dockerfile, that you reference in your Jenkinsfile, which will define a custom image for each CI job that runs. You install the packages onto the docker container, using devtools::install() within Jenkins. This container then gets tossed when the CI is done.
With this approach you don't have to worry about manually installing the packages yourself when you run your CI, and don't have to worry about conflicting namespaces across different packages.
This definitely has a higher start up cost, but I think you'll find it will be worth it in the long run for testing your R packages. Source: I also test internal R packages at my job.
sample Dockerfile
FROM docker.io/rocker/r-base
USER root
# Install packages needed for package development
RUN R -e 'install.packages(c("devtools", "rmarkdown", "testthat", "roxygen2"))'
You then reference this Dockerfile in the Jenkinsfile in order to install, test, and check the package (pipeline example below)
agent {
dockerfile {
args '-u root'
}
}
stages {
stage('Install') {
steps {
sh 'r -e "devtools::install()"'
}
}
stage('Test') {
steps {
sh '''
r -e "options(testthat.output_file = 'test-out.xml'); devtools::test(reporter = 'junit')"
'''
junit 'test-out.xml'
}
}
stage('Check') {
// Might need to modify expected ouput, depends on devtools version
steps {
sh '''
testOutput=$(R -e "devtools::check(args='--no-tests')" 2>&1)
echo "${testOutput}" | grep -q "0 errors ✔ | 0 warnings ✔ | 0 notes ✔"
'''
}
}
}
}