В Thu, 27 Mar 2025 13:26:47 +0100
Sergio Oller <sergiol...@gmail.com> пишет:
> Our current workaround kind of works, but when users expect to be able
> to install packages
> using renv or other tools that use install.packages to work; our
> wrapper is not that convenient.
Here's an idea that might help: since R CMD INSTALL launches R without
--vanilla, you can provide a system-wide startup file to your users that
would patch the installation function at runtime without patching the R
source code:
if (nzchar(Sys.getenv("R_LOCKDIR_PREFIX", "")))
invisible(suppressMessages(trace(
tools:::.install_packages,
tracer = quote(local({
prefix <- path.expand(Sys.getenv("R_LOCKDIR_PREFIX", ""))
lockdir <- NULL
# prepend the prefix when asked for lockdir and it's non-empty
makeActiveBinding(
"lockdir",
function (newval) {
if (!missing(newval)) lockdir <<- newval
if (nzchar(lockdir)) file.path(prefix, lockdir) else ""
},
parent.env(environment())
)
})),
print = FALSE
)))
This is the same workaround as you have originally suggested, making
the installation on a non-appendable filesystem possible at the cost of
losing atomicity, with the added downside that an update of R could
change the internals and break the patch.
In theory, the same approach could be used to wrap the function that
installs source packages [*] in order to first install the package in a
non-databrick directory, then populate a temporary directory on the
databrick with the package contents, then rename it to the intended
installation directory. This would be even more brittle and harder to
implement because the function is created during the runtime of
tools:::.install_packages.
It might be easier to support a patched version of R installed on
databricks than such an Rprofile.
--
Best regards,
Ivan
[*]
https://github.com/r-devel/r-svn/blob/0a905442c27b538c7626b21e262939873523f209/src/library/tools/R/install.R#L544
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
