Not sure whether it is the same issue as was raised here:
https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html
but in any case perhaps the problem could partially be remedied on line
245 of src/library/base/R/library.R by passing the lib.loc to
.getRequiredPackages2() ...here is a patch (untested)
Index: src/library/base/R/library.R
===================================================================
--- src/library/base/R/library.R (revision 74997)
+++ src/library/base/R/library.R (working copy)
@@ -242,7 +242,7 @@
pos <- 2
} else pos <- npos
}
- .getRequiredPackages2(pkgInfo, quietly = quietly)
+ .getRequiredPackages2(pkgInfo, lib.loc = lib.loc, quietly =
quietly)
deps <- unique(names(pkgInfo$Depends))
## If the namespace mechanism is available and the package
On 07/21/2018 12:34 PM, Martin Maechler wrote:
Benjamin Tyner
on Fri, 20 Jul 2018 19:42:09 -0400 writes:
> Here's a trick/workaround; if lib.loc is the path to your
> library, then prior to calling library(),
>> environment(.libPaths)$.lib.loc <- lib.loc
Well, that is quite a "trick" -- and potentially a pretty
dangerous one, not intended when making .libPaths a closure ....
I do think that there is a problem with R's dealing of R_LIBS
and other libPaths settings, notably when checking packages and
within that recompiling vignettes etc, where the R process
starts new versions of R via system() / system2() and then gets
to wrong .libPaths() settings,
and I personally would be very happy if we got reprex'es with
small fake packages -- possibly only easily reproducible on
unix-alikes ... so we could address this as a bug (or more than
one) to be fixed.
Notably with the 3.4.x --> 3.5.0 transition and my/our tendency
of having quite a few paths in R_LIBS / lib.loc / ... I've been
bitten by problems when the wrong version of package was taken
from the wrong library path ....
Martin
>> ------------------------------------------------------------------------
>> Good day,
>>
>> If there's a library folder of the latest R packages and
>> a particular package from it is loaded using the lib.loc
>> option, the dependencies of that package are still
>> attempted to be loaded from another folder of older
>> packages specified by R_LIBS, which may cause errors
>> about version requirements not being met. The
>> documentation of the library function doesn't explain
>> what the intended result is in such a case, but it could
>> reasonably be expected that R would also load the
>> dependencies from the user-specified lib.loc folder.
>>
>> --------------------------------------
>> Dario Strbenac University of Sydney Camperdown NSW 2050
>> Australia
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
