The choice is deliberate: the admin group on macOS corresponds to users that are allowed to install system-wide software so it allows all admins on the machine to install packages which is the expected way on macOS.
I think this choice is unfortunate as it contrasts with existing behavior on other platforms where one needs to explicitly request admin privileges by either using `sudo` or starting R as an admin.
On macOS, packages just go into the system lib ?silently? because of the write permissions granted via the `admin` group.
See also my comments further down for more details on this.
Also the versioning of the R framework as x.y is also deliberate - upgrading R to a new patch version does *not* require re-installation of packages, they work by design so in fact the system location is the safest way to do that. Also note that packages are never removed by the installer.
Thanks, I am aware that a patch update does not require a reinstallation as the packages are functional across minor versions.
I checked again and was indeed wrong, patch updates from the CRAN installer do not remove additional custom packages in the system lib.
I was confused by some custom approaches of mine which cause this behavior - sorry for this!
So out of the items listed in "The problem" they are all not true with the exception of the comparison with the other platforms, but even that difference is very subtle as it only affects the default on the first installation and not regular use (and I'm, not even sure it that is true since admin users can still install in the system location on other platforms).
On Linux you would need to do explicitly invoke `sudo R` to allow writing into the system lib.
The issue on macOS is that a regular start of `R` allows system lib write permissions.
In my current view I think a similar behavior as on Linux would be great, i.e. to explicitly having to request admin privileges for this task.
I don?t understand the part ?as it only affects the default on the first installation and not regular use? of your reply - could you clarify this?
Unless a user creates a user lib manually, packages will always go into the system lib - not only on first use - but I might be misunderstanding your comment here.
I would argue that the current setup tends to be a lot safer than the alternatives, because it allows commonly used packages to be installed at the system level and private packages to be installed at user level. This is also the design typically used on shared machines, where you separate local packages from user packages where local ones are installed by administrators - so exactly the same setup. Moreover R upgrades are a lot cleaner, since you can easily upgrade all system packages at once so you don't have to worry about individual users having stale packages - the biggest problem for admins.
Yes and no.
Sometimes system admins want to install certain packages globally - however, I never do so for the following reason:
Often this will lead to multiple package installations, i.e. one in the syslib and one in the user lib (if the user installs the package again for some reason which quite often happens).
Often these duplicated packages will have different versions and users are confused which one is actually loaded (the user lib one is as it is first in the path).
Aside from this practical point, Macs are rarely used in a shared way.
And even if, I?d highly favor having to request write permissions into the syslib rather it happening by default.
Imagine a scenario where the admin of a shared Mac constantly writes into the syslib (because this is the default). This syslib is then also used by other non-admin users on the system.
I don?t think this is a desired scenario and might cause lot?s of confusion (not even mentioning the fact if all people in this scenario are aware what?s going on given that this is a niche topic).
Here I think a one-time central installation of R and then only working with user libs (as on Linux) would be preferable.