Update on 2018-06-29: Please ignore the initial post below. I have changed the scope of the repository to be a complement to the official CRAN repository, and only provide binary R packages that are missing in the official repository. See https://macos.rbind.org for more information.
This is only relevant to macOS users. A week ago I experimented with creating a CRAN repository for the Hombrew version of R, and I wonder if there is anyone else in the community interested in it: https://yihui.name/en/2018/06/homebrew-binary-r-packages/
For now, I'm looking for two types of feedback:
Is there anything technically wrong in my process of building the binary R packages? The source code for building this repo is on Github: https://github.com/yihui/homebrew-r-packages, and all packages are automatically build on Travis (nightly). In short, I was just running R CMD INSTALL --binary (after brew install if necessary).
Are there any other packages that you use frequently, take long time to compile from source, or have heavy/complicated system dependencies? I'll be happy to add more binaries to this repo, but probably not too many (for reasons explained in the third section of my blog post).
Is there a benefit to using brew install r over brew cask install r-app? OpenBLAS?
As far as the current list, I'd suggest sf, which has a lot of dependencies. Building with Homebrew requires getting GDAL from the osgeo/osgeo4mac tap instead of the default. This issue has more useful details.
I think this is a mistake, maybe a better solution would be to fix the homebrew R script to work with the CRAN package binaries, or deprecate the homebrew version entirely in favor of the r-app cask.
Simon recently started using the same clang toolchain version to compile CRAN binaries as is available on homebrew, so getting homebrew-compiled R to work with them should be simpler than it previously was.
Sigh. Simon recently... and I have been waiting for this for years. I didn't know Simon was considering this at all.
Well, I don't think what I did was necessarily a mistake -- if using the Homebrew toolchain is a mistake, why would Simon start to move in this direction? The real mistake is probably CRAN not using the Homebrew toolchain before.
That said, I'm delighted to hear that Simon finally started considering Homebrew instead of providing the homemade versions of Clang (and previously, gfortran and tcltk, etc). I'll be thrilled if my experiment turns out to be totally unnecessary and will be happy to deprecate it (just a matter of a 301 redirect).
To be clear AFAIK Simon is not using homebrew on the CRAN macOS builders. However he is now using a clang toolchain that is the same versions and is setup in a similar / compatible way as that used by homebrew.
You can use the cask mentioned above to install the CRAN provided version of R and still use homebrew to manage it. The mistake I referred to was building another set of package binaries when CRAN already provides them for macOS. This duplicates work and uses additional ravis resources (which are already often overloaded for macOS builders).
I personally use homebrew to manage almost all of my packages on macOS and have contributed a few minor recipes, so I definitely understand the appeal of the system.
However I don't see the benefits of brew install r vs brew cask install r-app when the latter retains compatibility with the CRAN package binaries.
Okay. Thanks for all the information! That is very helpful to me. I'll take a closer look at the r-app cask. I had not used it before, but it seems I should try it now (sounds like brew cask uninstall r-app can cleanly uninstall it, which will make my happy enough).
To be clear, I definitely hate building these binary packages by myself, and would love use the CRAN binaries, if only all binaries exist. The missing RGtk2 binary has bothered me for years. I don't understand why CRAN has to provide a homemade version of Clang. There must be a reason, but this makes things hard to automate (and I hate editing ~/.R/Makevars).
Regarding the macOS builders on Travis, the extra burden I brought is quite minimal (often none). Packages are rebuilt only when newer versions appear on CRAN. And I don't really have a large number of packages in this repo (less than 30). So most of days, the builder only checks for new versions and exits.
Once CRAN becomes compatible with Homebrew, I'll happily tear down what I did here.
I have switched to brew cask install r-app, so that the number of binary packages I need to build has become significantly smaller. CRAN seems to be building sf well, so I won't build it in my repo.
