Regarding R_LIBS_USER

Hi,

As comments are welcome I will give my two cents and a patch suggestion :-)

2017-07-06 10:42 GMT+02:00 Dirk Eddelbuettel <edd at debian.org>:

I have used such settings (such as un-setting R_LIBS_USER or its
predecessors) for over a decade, it just works (if you give write
permissions). It clearly helps us at work because everybody sees by
the default the same packages. I have also spoken with different R
Core members and several find the default installation below $HOME and
in a versioned directory less than ideal as well.  But it ensures
writeability. Which I cannot do easily from the package.


So maybe the change was too abrupt, and I think I may revert it. I
generally prefer for packagers like myself to not divert from upstream
unless they have good reasom or are unintrusive (and eg the added
tab-completion we have here is both).  But leaving newbies without
installable directories is bad, as is possibly hiding existing
installations.

There are several entangled issues:
1. What should be the default places where packages are installed?
2. What should be the default places where packages are loaded from?

3. Ensuring that with the default R installation any user can install
packages

For 1., I believe packages should be installed at:
- /usr/lib/R/library, if they are given by a .deb package (core R packages)
- /usr/lib/R/site-library/, if they are given by a .deb package (other
packages)
- /usr/local/lib/R/site-library/, if the user has permissions
- ~/R/x86_64-pc-linux-gnu-library/3.4, (or somewhere else under $HOME,
otherwise)

For 2., I believe packages should be loaded from:
- ~/R/x86_64-pc-linux-gnu-library/3.4
- /usr/local/lib/R/site-library/
- /usr/lib/R/site-library/
- /usr/lib/R/library

I believe with 3.4.1-1 Dirk tried to move towards that configuration, and
for some reasons we ended in a situation where the R library in the HOME
directory was not considered to write into and was not considered to load
packages from.

This is how R works:

- When we use `library("package_name")`, the package_name is searched in
the directories given by .libPaths().

- When we use `install.packages("package_name")`, by default the package is
installed in the first element of .libPaths().

These two things make it very tricky to find a solution to 1, because:

- We can't change .libPaths() as we would break with how packages are
searched

- We may try to change install.packages() so instead of trying to install
to .libPaths()[1] by default it tries /usr/local/lib/R/site-library first.
We don't know how many things may break because they rely on that
assumption, we would need to test CRAN packages like checkpoint and packrat
and worse we don't know if we break some custom setups from users.
- We can't remove the home directory from .libPaths() because some users
won't be able to install packages there anymore nor find their packages,
unless they choose to do that in their Renviron file.

Considering this, the safest approach is to remove the home directory
approach from .libPaths() as Dirk tried to do. The main problem is that
there the personal directory approach failed and there was not enough
documentation in install.packages() to fix that.

Maybe a help message in install.packages would have helped. I attach a
DEP-3 compliant patch as a proposal. It works on my computer. I'm no expert
so your review is very welcome. The patch does a small change in how
install.packages works:

If the package can't be installed into .libPaths()[1]
(/usr/local/lib/R/site-library/), and if the user directory is NA (because
it is not set anymore in /etc/Renviron) then:
  * the default user directory is used instead: ~/R/%p-library/%v
  * and "Would you like to use \\n~/R/%p-library/%v \nto in the future to
install packages into?" is asked. if the answer is "yes", then it is
appended to the ~/.Renviron file.

I am a little pressed for time (at useR!) and system (main server is
ill, as is backup machine) but I should get a 3.4.1-2 out.

I hope this helps, I am missing the useR conference, I hope I can assist
next year :-)

Best,

Sergio