On ~/.rkward/library

[Thomas Friedrichsmeier]

On Tue, 24 Apr 2018 12:27:07 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> Am Dienstag, 24. April 2018, 11:17:18 CEST schrieb Thomas
> Friedrichsmeier:
> > I have just pushed a commit to offer R_LIBS_USER as standard
> > installation location, instead of ~/.rkward/library. The advantages
> > are that
> > 
> > a) This in line with what standalone R does.  
> 
> +1
> 
> > b) The directory is versioned, so packages built for R 3.4 will not
> > be seen by R 3.5 (and vice-versa).  
> 
> is that limited to certain platforms or coming with 3.5.0? i don't
> see any versioning in my R_LIBS_USER.

Hm. It should be set from Renviron (and since a _long_ time). Any
chance you have messed with that?

Of course it would also be really easy to offer ~/.rkward/library/3.5
(etc.) as a default location, and in fact that is what happens as a
fallback, when R_LIBS_USER is completely empty. But that would defeat
a), again.

I suppose a) will have priority over b).

> > One remaining concern is what to do with an existing
> > ~/.rkward/library. I do want to continue supporting custom
> > installation locations, but probably if ~/.rkward/library is found
> > among those, RKWard should probably suggest to remove it?  
> 
> it could try to "move" it to R_LIBS_USER, by freshly installing all
> packages to the new location, and only remove ~/.rkward/library if
> that was successful. without the versioning mentioned above it could
> also actually move packages directly, if the targets do not exist yet.
> 
> or is that asking for trouble?

It's simply asking for quite a deal of work for something users will be
faced with once (arguably a similar situation will then come up once a
year for new releases of R).

Regards
Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20180424/11e7d83c/attachment.sig>