[R-sig-Debian] Regarding R_LIBS_USER

[Dirk Eddelbuettel]

On Thu, Jul 06, 2017 at 11:43:22AM +0200, Johannes Ranke wrote:
> Hi,
> 
> > 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.
> 
> Could the package make /usr/local/lib/R/site-library owned by a dedicated 
> group, e.g. rlibs, so people could just adduser $USER rlibs? I do not see why 
> R users should read logs, which is what the adm group was apparently made for.

It could. I need to re-read the Debian Policy on this. In the past I
hesitated to create a new group _globally_ just for our one
application language. I don't think Python, Ruby, ... do either. Maybe
still better as a local policy?

> And then, this tip could be given when install.packages() fails, in addition 
> to the option to create a user (but not version) specific library. Usually R 
> libraries are not version specific, even though in the case of R 3.0.0 and 
> 3.4.0 compatibility was interrupted.
> 
> > 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.
> 
> I also like the idea of multiuser libraries, and in general the idea is that 
> the most current package versions play well together, and are better then 
> earlier versions. If this should not be the case, this should be an 
> exceptional situation, which may warrant a user specific library.

And users can currently get this behaviour by setting the env.var (or
altering .libPaths() from their .Rprofile or or or)

> So an alternative to reverting the change would be to keep your change, but to 
> give better support for people that 
> 
> a) have user (and version) specific libraries that were created from within R 
> in the past ("do you want to create a personal library instead")

Questions on install are tough. And discouraged.  Also, installing
user is root, we really want to ask each iser...

> b) want to use personal libraries for some good reason
> 
> via this list and maybe also via improved messages from R for the case that 
> install.package() fails.

I like a lot of the things you suggest, but I am not sure I know a
good way to get there just yet.

Easiest short-term (non-)fix is the reenable the R default even if
many of us do not like it.  We may need it as fallback.

Dirk

-- 
Three out of two people have difficulties with fractions.