From murdoch at stats.uwo.ca  Sat Mar 27 21:58:25 2010
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Sat, 27 Mar 2010 16:58:25 -0400
Subject: [Rd] update.packages(1)
In-Reply-To: <4BAE6F13.2040405@userprimary.net>
References: <alpine.LFD.2.00.1003251841410.8040@hafstormur.hafro.is>	<4BAE6DDD.5070709@stats.uwo.ca>
	<4BAE6F13.2040405@userprimary.net>
Message-ID: <4BAE7171.9080609@stats.uwo.ca>

On 27/03/2010 4:48 PM, Seth Falcon wrote:
> On 3/27/10 1:43 PM, Duncan Murdoch wrote:
>> On 25/03/2010 3:16 PM, Arni Magnusson wrote:
>>> I'm relaying a question from my institute's sysadmin:
>>>
>>> Would it be possible to modify update.packages() and related functions
>>> so that 'lib.loc' accepts integer values to specify a library from the
>>> .libPaths() vector?
>>>
>>> Many Linux users want to update all user packages (inside the
>>> R_LIBS_USER directory, e.g. ~/r/library) and none of the system
>>> packages (inside the /usr directory, e.g. /usr/lib64/R/library),
>>> because they don't have write privileges to update the system packages.
>>>
>>> Currently, this can be done by pressing 'y RET' for all the user
>>> packages and 'RET' for all the system packages. This hard work and
>>> careful reading when there dozens of packages. Another way is to run
>>>
>>>    update.packages(Sys.getenv("R_LIBS_USER"))
>>>
>>> or:
>>>
>>>    update.packages(.libPaths()[1])
>> You could also save some work by putting ask=FALSE, or ask="graphics" in
>> as another argument.  But isn't it easy enough to write your own
>> function as a wrapper to update.packages, suiting your own local
>> conventions?   It seems like a bad idea to make update.packages too
>> friendly, when there are several different friendly front-ends for it
>> already (e.g. the menu entries in Windows or MacOS GUIs).
>>
>>> But it would be nicer for the user to type
>>>
>>>    update.packages(1)
>>>
>>> using a 'pos' like notation to indicate the first element of the
>>> .libPaths() vector.
>>>
>>> ---
>>>
>>> A separate but related issue is that it would be nice if the
>>> R_LIBS_USER library would be the first library by default. Currently,
>>> my sysadmin must use Rprofile.site to shuffle the .libPaths() to make
>>> R_LIBS_USER first, which seems like a sensible default when it comes
>>> to install.packages() and remove.packages().
> 
> I'm confused.  AFAICT, R_LIBS_USER _is_ put first.  Following the advice
> in the Admin manual, I created a directory matching the default value of
> R_LIBS_USER (Sys.getenv("R_LIBS_USER") to see it).  Then when I start R,
> I get:
> 
>> .libPaths()
> [1] "/home/sfalcon/R/x86_64-unknown-linux-gnu-library/2.11"
> [2] "/home/sfalcon/build/rd/library"
> 
> Isn't that what you want?

I didn't try it, I just read the documentation (in ?.libPaths).  As I 
read it it says the order is

R_LIBS, R_LIBS_USER, .Library.site, .Library

and some of those components can be missing.

So another way to put the user libs first is to specify the site libs in 
.Library.site rather than in the environment variable.

Duncan Murdoch



[Rd] update.packages(1)
Duncan Murdoch