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 (includi
