On 07/24/2018 07:50 AM, Martin Maechler wrote:
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()
Seems reasonable to me.
Others / ideas?
Reproducible examples with small fake packages?
Or how about an example with a "real" CRAN package with just one dependency:
> dir.create("~/lib")
> list.files("~/lib")
character(0)
> install.packages("spam", lib = "~/lib", dependencies = TRUE)
> list.files("~/lib")
[1] "dotCall64" "spam"
> library(spam, lib.loc = "~/lib")
Error: package ‘dotCall64’ required by ‘spam’ could not be found
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
