Le 1 avr. 2022 ? 23:43, Simon Urbanek <simon.urbanek at R-project.org> a ?crit :
Patrick,
thanks for starting the discussion.
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.
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.
Packages are not compatible beyond the patch version so the current setup avoids the most common problem where users inadvertently use packages installed for an incompatible previous R version leading to crashes. To make R upgrades easy the R GUI Package Installer offers specifically the option to install packages from the previous R version. This allows for a clean and safe upgrade of R.
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). The user has full control over where they install a package - it's a simple click to change the default to whatever you prefer. Also I'd like to point out that once you start using the user library, it becomes the default for install.packages() so typically installing packages into system location requires deliberate choice over the user library(*). Note that the behavior of the user library is common across platforms, so I'm not really sure the is any real difference.
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.
I'd be happy to hear from more Mac user if there are reasons to change the default, but as I outlined the choices were deliberate after weighting the pros and cons. In my view the major issue with the proposal it that is would prevent sharing of packages, make R upgrades a lot harder and prevent admin users from using the current tools for package management - and that includes the ability to separate system and user packages on single-user machines.
Cheers,
Simon
(*) while looking into this I noticed there is a bug in the latest R GUI where Renviron and the GUI don't agree on the location of the user library (due to the addition of the architecture to the path) so I agree that the the GUI should be fixed to
match the location.
On Apr 2, 2022, at 2:08 AM, Patrick Schratz <patrick.schratz at gmail.com> wrote:
Dear fellow R users on macOS,
I'd like to discuss the current directory permissions set by the CRAN
installer for macOS (https://cran.r-project.org/).
The installers installs R into `/Library/Frameworks/R.framework/` with
775 permissions.
In contrast to 755, 775 also gives the defined group write permissions.
The group for `/Library/Frameworks/R.framework/` is `admin`.
Many users use a Mac in a single-user setup, i.e. only one user is using
the machine.
This is usually also an administrator, i.e. the user is a member of the
`admin` group.
## The problem
Being a member of `admin` group gives subsequently write access into the
R system library, i.e. the library which stores the package which are
bundled with the installer (base, MASS, parallel, etc.).
This is problematic for several reasons:
- user packages are mixed with system packages
- if a new R version is installed, all packages in the system library
are lost as they are getting overwritten by the CRAN installer
- on other platforms (Windows, Linux) the system library is not writable
by default, hence the behaviour of the macOS CRAN installer is different
from the other platforms
Besides the differing experience for users on macOS compared to other
platforms (which constantly causes confusion for R users switching
platforms), the above also causes many unneeded R package downloads,
e.g. users are forced to reinstall all packages for every patch version
update of R.
In case you are wondering why R does not offer to create a user library
as on other platforms: if the system library is writable (or R detects
any writable library configured in the repos option), the prompt will
not appear.
If a user manually creates a user library at the expected path (e.g
.`$HOME/Library/R/arm64/4.1/library`), R will pick it up and packages
will go into the user library.
However, most R users don't want to bother with this and are no experts
in their local library management.
## How can the following possibly be solved?
AFAICS the easiest way would be to set 755 instead of 775 permissions
for the `/Library/Frameworks/R.framework/` folder.
I don't see a reason why write permissions for the `admin` group would
be needed.
I've tested this in a few scenarios and did not face any issues.
Also I've come across an interesting observation while doing so:
While R in the terminal offers the creation of the user lib if
permissions are 755
```
[ins] r$> .libPaths()
[1]
"/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library"
[ins] r$> install.packages("<package>")
Warning in install.packages("<package>") :
'lib =
"/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library"'
is not writable
[ins] Would you like to use a personal library instead? (yes/No/cancel)
yes
[ins] Would you like to create a personal library
```
RStudio does it even silently in the background (which is quite nice
imo).
To reproduce:
1. Install R for Mac via the CRAN installer
2. `sudo chmod -R 755 /Library/Frameworks/R.framework/`
3. `R -q -e ".libPaths()"` (should only return the system library)
4. Open RStudio
5. `R -q -e ".libPaths()"` (should return two libraries, with the user
lib being the first)
If for some reasons 755 cannot be set for the `R.frameworks`
directories, then the group defined for `R.frameworks` (and recursive
directories) could possibly be changed to prevent direct writes access
to the R system lib.
Last, I wanted to ask if the source code for the CRAN installer is
publicly available? I could not find it and would be interested to take
a look into it.
If this is not possible for some reason, I would also be interested in
getting to know the reason for this decision.
Best regards,
Patrick
[[alternative HTML version deleted]]