You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, I've identified a relatively rare bug in specific parameter configurations. It happens when attempting to run a check for a source package, which requires installation during building due to S expressions with the desired libpath value being different from the current .libPaths(). Then, when one or more strong dependencies of the package to be checked were supposed to come from libpath and are not satisfiable via .libPaths(), the rcc_init internal will fail due to build failure, and build failed due to missing dependencies. I believe I've also identified the issue, and it is coming from that block:
out<- sub("(checking for file .)/.*DESCRIPTION(.)",
"\\1.../DESCRIPTION\\2", out, perl=TRUE)
callback(out)
callback(err)
}
}
proc$get_built_file()
}
)
Unfortunately, callr ignores "R_LIBS_USER" when setting up libraries in the new process (I'm pretty sure deliberately), which can be tested using this example
This means that the way build_package internally currently works, the subprocess building the package never gets the appropriate libpath set (with all the dependencies required to build a package with SEXP). Unfortunately, pkgbuild_process$new() does not accept a libpath parameter, so as far as rcmdcheck is concerned, I believe the fix is to replace with_envvar with with_libpath, and so the building process (which always uses current .libPath) can adequately use desired dependencies.
I'll try to prepare a PR with a suggested fix
Thanks for all your work under this package!
The text was updated successfully, but these errors were encountered:
Hello!
Today, I've identified a relatively rare bug in specific parameter configurations. It happens when attempting to run a check for a source package, which requires installation during building due to S expressions with the desired
libpath
value being different from the current.libPaths()
. Then, when one or more strong dependencies of the package to be checked were supposed to come fromlibpath
and are not satisfiable via.libPaths()
, thercc_init
internal will fail due to build failure, and build failed due to missing dependencies. I believe I've also identified the issue, and it is coming from that block:rcmdcheck/R/build.R
Lines 19 to 46 in 6125f20
Unfortunately, callr ignores
"R_LIBS_USER"
when setting up libraries in the new process (I'm pretty sure deliberately), which can be tested using this exampleThis means that the way
build_package
internally currently works, the subprocess building the package never gets the appropriate libpath set (with all the dependencies required to build a package with SEXP). Unfortunately,pkgbuild_process$new()
does not accept a libpath parameter, so as far as rcmdcheck is concerned, I believe the fix is to replacewith_envvar
withwith_libpath
, and so the building process (which always uses current .libPath) can adequately use desired dependencies.I'll try to prepare a PR with a suggested fix
Thanks for all your work under this package!
The text was updated successfully, but these errors were encountered: