clarification of library/require semantics

Recently I have added a lib.loc argument to require, so that
it is more consistent with library. However, there are some oddities
that folks have pointed out, and we do not have a documented description
of the semantics for what should happen when the lib.loc parameter is
provided.

  Proposal: the most common use case seems to be one where any other
dependencies, or calls to library/require should also see the library
specified in the lib.loc parameter for the duration of the initial call
to library. Hence, we should modify the library search path for the
duration of the call (via .libPaths).

 The alternative, is to not do that. Which is what happens now.

 Both have costs, automatically setting the library search path, of
course, means that users that do not want that behavior have to manually
remove things from their library. But if almost no one does that, and
most folks I have asked have said they want the lib.loc parameter to be
used for other loading.

  Comments?

There is a parallel set of issues with loadNamespace and the dependent 
namespaces it loads.  I think I would want the same semantics (whatever 
they are) for loadNamespace and library.

I set my standard libraries in R_LIBS, so when I use lib.loc it is for 
experimental things.  So I would neither want the .libPaths changed nor 
be affected if they were.

Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

I set my standard libraries in R_LIBS, so when I use lib.loc it is
for experimental things.  So I would neither want the .libPaths
changed nor be affected if they were.

With the current semantics, if one is testing a _collection_ of
experimental packages that depend on each other, the only way to test
the collection is to modify .libPaths.

Setting lib.loc only allows one to test a single experimental package
against dependencies picked up from R_LIBS.

Robert's proposal, as I understand it, would change the meaning of
lib.loc so that dependencies would be resolved there --- allowing a
collection of experimental packages to be tested against each other.

The current behavior could be replicated in this case by putting a
given experimental package in a library by itself.

Clearly, each choice has a tradeoff.  I understand that if one most
often tests a single independent experimental package, then the
current behavior is most convenient.

My preference is for lib.loc grabbing dependencies because I more
often deal with packages that have dependencies that I want to test
together.


+ seth