Re: [Rd] Request: better default R_LIBS_USER
On Thu, Mar 23, 2023 at 4:57 PM Gabriel Becker wrote: > Thanks for being interested in making R better. Its great to see engagement > from a new "virtual face", so to speak. That said, without speaking for > R-core, my experience is that the R-project and R-core team place a very high > premium on backwards compatibility. Yes, this is something I value in the software I use: backwards compatibility should be of utmost importance. However, there's a difference between being extremely dutiful with backwards-incompatible changes, and making them taboo. There's such a thing as too much inflexibleness. And you must make backwards-incompatible changes at some point. Otherwise your software eventually becomes stale and obsolete. > They will make breaking changes, on occasion, but its rare and extreme for > them to do so. As it should be. But rare doesn't mean non-existent. > I personally don't think the amount of convenience/modern conceptual best > practices adherence we're talking about here rises to the level of justifying > a breaking change put in quickly. Let me put it this way: I work with several dozens of projects on my Linux system, and R is the *only* one that creates a directory directly on top of my home directory, it has been the only one doing so for at least the past 10 years, if not *ever*. Most projects with poor considerations towards the user's home directory at least have the decency to start the name of the directory with a dot: e.g. ~/.R (as opposed to ~/R). But I'm a programmer, R is just one of the many projects I dabble with. If on the other hand R is the main project *you* work with (if not the only one), then I can imagine how *you* don't see a problem. But that doesn't mean there isn't one. I bet many casual users of R are annoyed by precisely the same thing, but they aren't going to bother investigating and contacting you like I did. > As for why I'm calling this a breaking change, see inline: > > On Thu, Mar 23, 2023 at 12:49 PM Felipe Contreras > wrote: >> >> > Just expand %U to both: >> > >> > paste(c( >> > file.path(home, ".local", "lib", "r", x.y), >> > file.path(home, "R", paste0(R.version$platform, "-library"), >> > x.y) >> > ), collapse = ":") >> > >> > Then R would install packages to the new location in new installations >> > by default, but still use packages from the old location if present. >> >> This would work, would it not? > > > So off the top of my head, this would mean that people who have versions of R > from before and after that change installed simultaneously would, by default > have package libraries that live in completely different places on the drive. > > Does that preclude a change like this from ever being made? No, but it does > seem more like a major version change than a minor version change to me. > > For an example of why this could be a breaking change, i'd be willing to bet > there are shell scripts out there which assume the user directories live at > ~user/R// and detect them as such. Do I think its common? No. Do > I think its the right way to do whatever that shell script is doing? No, but > I'd be surprised if there wasn't code that does it somewhere. And that code > will/would break under your proposed change. Yes, bad code breaks. That is the nature of using bad code. But that's why good software doesn't rely on hard-coded paths, and instead relies on methods to fetch them automatically. If I wrote a software that somehow needed a path to check for Ruby gems, I wouldn't use a hardcoded path such as `$HOME/.local/share/gem/ruby/3.0.0`, I would use the output of `ruby -e 'puts Gem.user_dir'`. Instead of hardcoding a path, why don't you provide a functionality similar to `ruby -e 'puts Gem.user_dir'` so that scripts can use that instead? That being said, I don't even buy this hypothetical scenario, because the location where R packages are installed isn't even `~user/R//`, the is always the same, what is different is the *platform*, and it's not even , it's `major.minor`. How is this hypothetical shell script supposed to figure out this directory in reality? What is the actual command? * Ruby: find $(ruby -e 'puts Gem.user_dir') * R: find $() >> > Moreover, this location is going to change the next time the minor >> > version is bumped anyway. >> >> Or just change it for the next version of R. > > > All of the above said, I do actually agree that it would be nice to change > the default in the long term (including for mac builds from source). Perhaps > this could be put on the list of possible changes for R 5.0, to be bundled > with other as-yet undecided breaking changes, members of R-core feel the same > way. I'm perfectly fine with this change being part of the next major release (as long as it actually happens at some point), but wasn't this *already* changed? Here's a link to a git mirror (because the last time I used svn was in 2005):
Re: [Rd] Request: better default R_LIBS_USER
Small but crucial typo correction: Perhaps this could be put on the list of possible changes for R 5.0, to be > bundled with other as-yet undecided breaking changes, members of R-core > feel the same way. > *if* members of R-core feel the same way. ~G > > Best, > ~G > > >> Cheers. >> >> -- >> Felipe Contreras >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
Felipe, Thanks for being interested in making R better. Its great to see engagement from a new "virtual face", so to speak. That said, without speaking for R-core, my experience is that the R-project and R-core team place a very high premium on backwards compatibility. They will make breaking changes, on occasion, but its rare and extreme for them to do so. I personally don't think the amount of convenience/modern conceptual best practices adherence we're talking about here rises to the level of justifying a breaking change put in quickly. As for why I'm calling this a breaking change, see inline: > On Thu, Mar 23, 2023 at 12:49 PM Felipe Contreras < felipe.contre...@gmail.com> wrote: > > Just expand %U to both: > > > > paste(c( > > file.path(home, ".local", "lib", "r", x.y), > > file.path(home, "R", paste0(R.version$platform, "-library"), > x.y) > > ), collapse = ":") > > > > Then R would install packages to the new location in new installations > > by default, but still use packages from the old location if present. > > This would work, would it not? > So off the top of my head, this would mean that people who have versions of R from before and after that change installed simultaneously would, *by default* have package libraries that live in completely different places on the drive. Does that preclude a change like this from ever being made? No, but it does seem more like a major version change than a minor version change to me. For an example of why this could be a breaking change, i'd be willing to bet there are shell scripts out there which assume the user directories live at ~user/R// and detect them as such. Do I think its common? No. Do I think its the right way to do whatever that shell script is doing? No, but I'd be surprised if there wasn't code that does it somewhere. And that code will/would break under your proposed change. > Moreover, this location is going to change the next time the minor > > version is bumped anyway. > > Or just change it for the next version of R. > All of the above said, I do actually agree that it would be nice to change the default in the long term (including for mac builds from source). Perhaps this could be put on the list of possible changes for R 5.0, to be bundled with other as-yet undecided breaking changes, members of R-core feel the same way. Best, ~G > Cheers. > > -- > Felipe Contreras > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
Hi, Pinging. On Thu, Mar 16, 2023 at 7:17 PM Felipe Contreras wrote: > On Thu, Mar 16, 2023 at 4:08 PM Dirk Eddelbuettel wrote: > > On 16 March 2023 at 13:39, Felipe Contreras wrote: > > | R should do the same: it should install packages to somewhere inside > > | ~/.local by default. > > rather than asking a few million R users to adjust from past > > practice. > > Why would they have to adjust anything? > > Just expand %U to both: > > paste(c( > file.path(home, ".local", "lib", "r", x.y), > file.path(home, "R", paste0(R.version$platform, "-library"), x.y) > ), collapse = ":") > > Then R would install packages to the new location in new installations > by default, but still use packages from the old location if present. This would work, would it not? > Moreover, this location is going to change the next time the minor > version is bumped anyway. Or just change it for the next version of R. Cheers. -- Felipe Contreras __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
On Thu, Mar 16, 2023 at 6:39 PM Dirk Eddelbuettel wrote: > > > On 16 March 2023 at 17:15, Henrik Bengtsson wrote: > | We're all starting out with a fresh R_LIBS_USER once a year when a new > | minor version of R is released, > > Maybe not "we all". I don't, and I know other Linux users who don't force a > rebuild unless needed (as with R 3.6.* -> R 4.0.0). Then you are not using the default. And BTW, that's why the default location probably should be in a "4" directory, not "4.2". And since it's even more unlikely that the platform is going to change from one version to the next: ~/.local/share/R/4 Or something like that. -- Felipe Contreras __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
On Thu, Mar 16, 2023 at 4:08 PM Dirk Eddelbuettel wrote:
>
>
> On 16 March 2023 at 13:39, Felipe Contreras wrote:
> | I see R by default installs packages in ~/R. I know I can change the
> | default directory with R_LIBS_USER, but software shouldn't be
> | polluting the home directory.
> |
> | For example both python and node install packages to ~/.local/lib,
> | ruby to ~/.local/share. They don't install to for example ~/node.
> |
> | R should do the same: it should install packages to somewhere inside
> | ~/.local by default.
>
> Use of ~/.local is a fairly recent convention (relative to the time R has
> been around, which is now decades) and one which R supports already eg in the
> (rather useful) portable config directories:
>
>> tools::R_user_dir("r2u")
>[1] "/home/edd/.local/share/R/r2u"
>>
>
> Your best bet really to govern your .libPaths from your Rprofile.site and
> Renviron.site
I already have fixed it for myself, my request was about the default,
so most users don't have to fix it for themselves too.
> rather than asking a few million R users to adjust from past
> practice.
Why would they have to adjust anything?
Just expand %U to both:
paste(c(
file.path(home, ".local", "lib", "r", x.y),
file.path(home, "R", paste0(R.version$platform, "-library"), x.y)
), collapse = ":")
Then R would install packages to the new location in new installations
by default, but still use packages from the old location if present.
Moreover, this location is going to change the next time the minor
version is bumped anyway.
Cheers.
--
Felipe Contreras
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
On 16 March 2023 at 17:15, Henrik Bengtsson wrote:
| We're all starting out with a fresh R_LIBS_USER once a year when a new
| minor version of R is released,
Maybe not "we all". I don't, and I know other Linux users who don't force a
rebuild unless needed (as with R 3.6.* -> R 4.0.0).
R signals clearly when a rebuild is needed at a major version change, and we
had this (if I recall correctly) about twice in the six or so years. I carry
my directories over with ease from most (major) release to the next: By doing
nothing as my .libPaths has no version number in.
[ In fairness the last few upgrades were semi-dirtied because package needing
a graphics device needed a rebuild as the tireless Paul Murrell extends
capabilities and hence API interfaces. But that affects usually half a dozen
out of maybe hundreds of installed packages. ]
[ But your post was helpful in adding how to define a version, or arch, or
... handle for which `help(".Library")` has all the relevant details. ]
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
> Your best bet really to govern your .libPaths from your Rprofile.site and
Renviron.site ...
To do this for any version of R, one can add:
R_LIBS_USER=~/.local/share/R/%p-library/%v
to ~/.Renviron or the Renviron.site file. This automatically expands
to the platform and R x.y version early on when R starts up, e.g.
~/.local/share/R/x86_64-pc-linux-gnu-library/4.2.
> rather than asking a few million R users to adjust from past practice.
We're all starting out with a fresh R_LIBS_USER once a year when a new
minor version of R is released, so changing the default should be
doable without major troubles. On MS Windows, this move has already
been made. When R 4.2.0 was released, the default R_LIBS_USER location
on MS Windows was changed, similarly, to the Local Application Data
directory in R (>= 4.2.0), e.g.
C:\Users\alice\AppData\Local\R\win-library\4.2.
/Henrik
On Thu, Mar 16, 2023 at 3:09 PM Dirk Eddelbuettel wrote:
>
>
> On 16 March 2023 at 13:39, Felipe Contreras wrote:
> | I see R by default installs packages in ~/R. I know I can change the
> | default directory with R_LIBS_USER, but software shouldn't be
> | polluting the home directory.
> |
> | For example both python and node install packages to ~/.local/lib,
> | ruby to ~/.local/share. They don't install to for example ~/node.
> |
> | R should do the same: it should install packages to somewhere inside
> | ~/.local by default.
>
> Use of ~/.local is a fairly recent convention (relative to the time R has
> been around, which is now decades) and one which R supports already eg in the
> (rather useful) portable config directories:
>
>> tools::R_user_dir("r2u")
>[1] "/home/edd/.local/share/R/r2u"
>>
>
> Your best bet really to govern your .libPaths from your Rprofile.site and
> Renviron.site rather than asking a few million R users to adjust from past
> practice.
>
> Also: personal preferences differ. I think of Linux as multi-tenant and
> expect other (even system) users to have access to packages I install. So I
> am happy with this default --- which goes after all back to fruitful
> discussion in a bar in Vienna with Kurt and Fritz some 20 years ago:
>
>> .libPaths()
>[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
>[3] "/usr/lib/R/library"
>>
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: better default R_LIBS_USER
On 16 March 2023 at 13:39, Felipe Contreras wrote:
| I see R by default installs packages in ~/R. I know I can change the
| default directory with R_LIBS_USER, but software shouldn't be
| polluting the home directory.
|
| For example both python and node install packages to ~/.local/lib,
| ruby to ~/.local/share. They don't install to for example ~/node.
|
| R should do the same: it should install packages to somewhere inside
| ~/.local by default.
Use of ~/.local is a fairly recent convention (relative to the time R has
been around, which is now decades) and one which R supports already eg in the
(rather useful) portable config directories:
> tools::R_user_dir("r2u")
[1] "/home/edd/.local/share/R/r2u"
>
Your best bet really to govern your .libPaths from your Rprofile.site and
Renviron.site rather than asking a few million R users to adjust from past
practice.
Also: personal preferences differ. I think of Linux as multi-tenant and
expect other (even system) users to have access to packages I install. So I
am happy with this default --- which goes after all back to fruitful
discussion in a bar in Vienna with Kurt and Fritz some 20 years ago:
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
>
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
