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
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
Good day, Now that I read about Renaud's problem, I realise that it is effectively the same as mine. -------------------------------------- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia
Martin Maechler
2018-Jul-24 11:50 UTC
[Rd] Library lib.loc Option Ignored for Dependencies
>>>>> Benjamin Tyner >>>>> on Sat, 21 Jul 2018 13:42:43 -0400 writes:> 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 This - directly - fails even more miserably e.g. in my own setup when I have dependency to my package. But it seems a good idea to use 'lib.loc', and safer and probably better than the current code maybe to use .getRequiredPackages2(pkgInfo, lib.loc = c(lib.loc, .libPaths()), quietly = quietly) instead of the current code which uses lib.loc = NULL equivalently to lib.loc = .libPaths() Others / ideas? Reproducible examples with small fake packages? Martin > 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