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
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> ------------------------------------------------------------------------ > 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 >
Martin Maechler
2018-Jul-21 16:34 UTC
[Rd] Library lib.loc Option Ignored for Dependencies
>>>>> 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