Vectorize library()

[gmbecker]

Summary

library currently takes the name of a single package (either in the form of a character vector of length one, or via NSE). I propose library accept a vector of packages and load them all (plus their dependnecies) in the order that they appear.

Background.

R supports versioned dependencies, which nearly always come in the form of pkg (>= vers).

R also supports vectors of library paths. And, in particular, R supports different versions of the same package appearing at different points in its set of libpaths, at least in principle.

In practice these two capabilities combine to form some sharp-edged corner cases where valid, installed packages can be unloadable.

Reason

Consider the following dependency structure between packages

pkgA: pkgB (>= 0.5.0)

pkgC: pkgB (>= 0.6.0)

Consider the following multi-libpath setup:

~/pth1/: pkgA, pkg B [0.5.1]
~/pth2/: pkg C, pkg B [0.6.5]

And consider that we have the libpath c("~/pth1/", "~pth2").

If we do

library(pkgA)

Things will work great.

Same if we do

library(pkgC)

BUT, if we do

library(pkgA)
library(pkgC)

pkgC will not be able to be loaded, because an insufficient version of pkgB will already be loaded.

Proposal:

Support

library(c("pkgA", "pkgC"))

Which would result in the following search path: pkgA, pkgB [0.6.5], pkgC.

Conceptual Feasibility

A first pass at this could be simply resolving the recursive dependencies as is currently done, and then combining those for a unification pass at the end. Some care will be needed to get the order right, but I'm confident it's doable.

Technical Approach

TBD

[gmbecker]

@hturner I may have done something wrong, its unclear to me why this isn't showing up in Proposals, and how I'd put it there?

[llrs]

This was tagged as Ideas. Maybe it can be moved to proposals.

[hturner]

Project proposals can be made by adding a project page for the website as described here: https://contributor.r-project.org/r-project-sprint-2023/projects/ideas-and-proposals.html#proposals (don't skip step 5 which triggers the post to Proposals here).

As this is a completely new idea - not previously discussed on Bugzilla or the R-devel mailing list AFAIK - I think it would be good to get some indication from an R Core member that a patch along these lines would be welcome/seriously considered before making a formal proposal.

[llrs]

Nice idea! I have encountered this problem several times (when developing a shiny app and having packages installed by the shiny user and others by the system or a user. Sometimes people add their libraries and depending on the order they cause problems).

How would this proposal handle arguments mask.ok, include.only and exclude? Would they need to be handle a list or simply handle as it they are currently handled (I haven't checked but probably if not in the package they values are omitted). I'm thinking in the (edge) case of two packages that export a function with the same name but you want to mask one of them (A::fun, C::fun). How would that work for instance in library(c("A", "C"), mask.ok = c(C = "fun"))? Would the name of the character be useful to decide which one is ok to mask? (in the example I would expect the C::fun be masked by A::fun (aka in the inverse order).

If this doesn't go ahead, perhaps a function could be implemented to check these situations in the .libPaths (in a package if not in base?).