From sfalcon at fhcrc.org  Sat Nov  5 20:21:05 2005
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Sat, 05 Nov 2005 11:21:05 -0800
Subject: [Rd] clarification of library/require semantics
In-Reply-To: <Pine.LNX.4.61.0511041902140.5439@gannet.stats> (Brian Ripley's
	message of "Fri, 4 Nov 2005 19:06:57 +0000 (GMT)")
References: <436BAEE4.2030604@fhcrc.org>
	<Pine.LNX.4.61.0511041902140.5439@gannet.stats>
Message-ID: <m2sluarjdq.fsf@macaroni.local>

On  4 Nov 2005, ripley at stats.ox.ac.uk wrote:
> 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



[Rd] clarification of library/require semantics
Seth Falcon