Pass .libPaths() as R_LIBS to quarto subprocess

[cderv]

Related to

• Quarto vignettes use the installed version of the package, but Rmd vignettes use the current dev version r-lib/pkgdown#2830
• Windows CI Errors on Package Re-build #217

This package is using processx::run() and not callr::r() to trigger the subprocess.

Environment variables are inherited by default, but if .libPaths() is modified during the R session before calling quarto_render(), this is unknown to the R process in Quarto processing.

This PR insures that by default .libPaths() is passed to the subprocess through R_LIBS environment variable.

This way, temporary install of the package, like with pkgdown or Quarto vignettes should not fail.

[hadley]

It'd be worth double checking for other env vars that callr sets but processx doesn't.

[cderv]

Yeah I didn't want to just copy callr which aims to be more generic. Other env vars are the following

> callr:::setup_context
function (options) 
{
    repos <- libpath <- system_profile <- user_profile <- load_hook <- NULL
    make_path <- function(x) paste(x, collapse = .Platform$path.sep)
    options <- within(options, {
        profiles <- make_profiles(system_profile, user_profile, 
            repos, libpath, load_hook, env)
        tmp_files <- c(tmp_files, profiles)
        envs <- make_environ(profiles, libpath, env)
        tmp_files <- c(tmp_files, envs)
        save_env <- c("R_ENVIRON", "R_ENVIRON_USER", "R_PROFILE", 
            "R_PROFILE_USER", "R_LIBS", "R_LIBS_USER", "R_LIBS_SITE")
        keep_set <- save_env %in% names(env)
        save_set <- !keep_set & save_env %in% names(Sys.getenv())
        save_nms <- paste0("CALLR_", save_env, "_BAK")
        env[save_nms[keep_set]] <- env[save_env[keep_set]]
        env[save_nms[save_set]] <- Sys.getenv(save_env[save_set])
        env <- env[setdiff(names(env), save_nms[!keep_set & !save_set])]
        if (is.na(env["R_ENVIRON"])) 
            env["R_ENVIRON"] <- envs[[1]]
        if (is.na(env["R_ENVIRON_USER"])) 
            env["R_ENVIRON_USER"] <- envs[[2]]
        if (is.na(env["R_PROFILE"])) 
            env["R_PROFILE"] <- profiles[[1]]
        if (is.na(env["R_PROFILE_USER"])) 
            env["R_PROFILE_USER"] <- profiles[[2]]
        if (is.na(env["R_LIBS"])) 
            env["R_LIBS"] <- make_path(libpath)
        if (is.na(env["R_LIBS_USER"])) 
            env["R_LIBS_USER"] <- make_path(libpath)
        if (is.na(env["R_LIBS_SITE"])) 
            env["R_LIBS_SITE"] <- make_path(.Library.site)
        env["CALLR_IS_RUNNING"] <- "true"
    })
    call_user_hooks(options)
}

So there is also R_LIBS_USER and R_LIBS_SITE, but it seems to be useful in very specific situation where a user would modify them inside a R session before calling quarto_render... It seems R_LIBS was enough for the current situation.

R_PROFILE_USER / R_PROFILE and R_ENVIRON_USER / R_ENVIRON are related to R Startup. I try to think of situation where those would be modified in an R session and I did find any compelling. As those R startup env, they would be set already outside, and quarto_render would pick them up.

They could be helpful to modify startup behavior of R by Quarto inside quarto_render(). I wanted to wait for use case before doing that.

So R_LIBS seemed the obvious one. Though I still need to understand and fix the problem on Windows CI.

[hadley]

That analysis makes sense to me!