[Rd] Request: better default R_LIBS_USER

[Felipe Contreras]

On Thu, Mar 23, 2023 at 4:57 PM Gabriel Becker <gabembecker using gmail.com> 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 <felipe.contreras using 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/<os>/<version> 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/<os>/<version>`, the <os> is always the same, what is
different is the *platform*, and it's not even <version>, 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):

https://github.com/wch/r-source/commit/9196047eea

Isn't this a change for the default location? Not in 4.0, not in 5.0,
but in 4.2. So there's nothing that should prevent this from happening
for Linux in 4.3. Is there?

Cheers.

-- 
Felipe Contreras