[Rd] Library lib.loc Option Ignored for Dependencies

[Martin Maechler]

>>>>> 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