On Sat, 1 Jul 2017 12:16:53 -0500 Dirk Eddelbuettel wrote:
On 1 July 2017 at 11:19, Pavel N. Krivitsky wrote:
| Package: r-base
| Version: 3.4.1-1
| Severity: important
|
| By default, when asked to install or upgrade a package as a non-root user, R
| creates a subdirectory in the home directory for such packages, and puts it at
| the front of the library path. After the upgrade, I get the following:
|
| $ R
|
| R version 3.4.1 (2017-06-30) -- "Single Candle"
| Copyright (C) 2017 The R Foundation for Statistical Computing
| Platform: x86_64-pc-linux-gnu (64-bit)
|
| [SNIP]
|
| > update.packages(ask=FALSE)
| --- Please select a CRAN mirror for use in this session ---
| Warning in install.packages(update[instlib == l, "Package"], l, contriburl =
| contriburl, :
| 'lib = "/usr/lib/R/site-library"' is not writable
| Would you like to use a personal library instead? (y/n) y
| Would you like to create a personal library
| NA
| to install packages into? (y/n) y
| Error in install.packages(update[instlib == l, "Package"], l, contriburl =
| contriburl, :
| unable to create ‘NA’
|
|
| For some reason, rather than creating the usual path (i.e.,
| $HOME/R/$architecture/$Rversion), the path it looks for is NA.
Let me add a resounding ME TOO. This is a bug and I want it fixed.
Not 'some reason': the same reason we have been doing this for 15 years (!!).
Multi-user use comes first.
Obviously, the way you are thinking about multi-user is very different
from the way I think about it. I teach statistics, so I can imagine
that in an R lab I want two different sets of available packages: (a) a
carefully vetted set of packages in a site-library, and (b) local
packages that an individual student is experimenting with.
That is, I want the student to be able to download packages from CRAN
and try them out, or even develop new packages herself. The default
mechanism works just fine for that. The student can play with anything
in a local directory, but can't muck with the system files.
The mechanism of auto-creating the local directory goes back farther
than 15 years. It may have been in core S since the time of the blue
book. (Most of the users at Bell Labs were also developers who wanted
to have local copies for stuff in progress and site-libraries for stuff
that was mature enough to share). If not, it was one of the first
things that Doug Martin asked Bill Dunlap to add into Splus.
R> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library" "/usr/lib/R/library"
R>
And you are advised to create a group-writable /usr/local/lib/R/site-library, ie
edd@bud:~$ ls -ld /usr/local/lib/R/site-library/
drwxrwsr-x 93 root adm 4096 Jun 25 15:04 /usr/local/lib/R/site-library/
edd@bud:~$ id
uid=1000(edd) gid=1000(edd)
groups=1000(edd),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),50(staff),109(lpadmin),125(sambashare)
edd@bud:~$
Ie it belongs to 'adm', I am 'adm' as well and so I can write there.
That solves the problem for a single admin user, not the problem for a
lab environment.
Should you not like this, you are free to define R_LIBS_USER, the variable I
comment-out by default for the package, and set it in one of the 'site' files
below /etc/R.
May I gently suggest that if you don't like the default behavior from
the R Core Team, that you hack your local copy rather than propagating
your personal preferences downstream.
Dirk
|
--
Russell Almond
Associate Professor, Measurement & Statistics
Educational Psychology and Learning Systems
1114 W. Call St.
Florida State University
Tallahassee, FL 32306
ralm...@fsu.edu; alm...@acm.org
http://ralmond.net/