On Thu, Mar 23, 2023 at 4:57 PM Gabriel Becker <gabembec...@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.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/<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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
