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().
This is R version 2.10.1 (2009-12-14) on x86_64-redhat-linux-gnu (Fedora
11).
I didn't write it, but I suspect the current behaviour was intentional.
Without it, it would be hard to put the user library last, since
.libPaths() adds things at the front. Now you have a choice: use the
R_LIBS_USER environment variable to put it last, use a line in your
Rprofile.site file to put something first.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel