[R-SIG-Mac] Homebrew [was: from Mac to LInux?]

[Simon Urbanek]

Rainer,


> On 3/04/2020, at 10:01 PM, Rainer M Krug <Rainer using krugs.de> wrote:
> 
> Thanks a lot for your detailed response - it is very much appreciated.
> 
>> On 2 Apr 2020, at 22:30, Simon Urbanek <simon.urbanek using r-project.org> wrote:
>> 
>> 
>> 
>>> On 2/04/2020, at 9:15 PM, Patrick Schratz <patrick.schratz using gmail.com> wrote:
>>> 
>>> AFAIK most people on that list would vote hard against installing R via homebrew for several reasons - maybe there should be a section about this on the R dev / CRAN page to address this topic, @Simon? Otherwise this will come up again and again.
>>> 
>> 
> 
> 
>> That main objection is that people are mixing Homebrew with CRAN and vice-versa which leads to many problems. You cannot use packages from CRAN when using Homebrew, period, and you have to be really careful if you want to mix Homebrew libraries (not anything R-related) with CRAN (it is doable if you know what you're doing).
> 
> 
> This is definitely true (and I assume, you are referring to CRAN binary packages).
> 
> But I am wondering: I am always installing from the normal CRAN mirrors, and my R installation (homebrew) always installs from source. I never use `type = “source”`in the installation for packages. 
> 
> My question: when would I install incompatible packages (I assume, you mean binary packages for Mac) from CRAN?
> 

Maybe you wouldn't but I have seen people do it.


> 
>> 
>> The fundamental issue is that package managers like Homebrew replace system libraries with their own (for new features/updates that the system libraries don't provide) which break anything that relies on the system library. Out of all the package managers Homebrew the only one that is trying to address the issue by trying to separate them, but even that has been diverging over time.
>> 
>> The second issue is that they are increasingly replacing toolchains (compilers) with their own builds, which makes everything incompatible in explosive ways (things just segfault). Making sure that a compiler toolchain is stable is actually non-trivial and many packager manager authors/maintainers have little experience with this. That used the be the primary reason to avoid them, because it was just normal that the released binaries were miscompiled and things would break all the time. Fortunately, I think that has gotten better over time.
>> 
>> If you stick only with Homebrew, then you're likely ok, but you're on your own and have to compile all packages form sources.
> 
> This is true, but I did not encounter big problems. And this is, why I thought loud in suggesting to setup a (non official!) homebrew tap to install the packages, similar to how it is in linux (Debian).
> 
>> Majority of our time as CRAN maintainers for the binary releases is about providing dependent libraries for packages and making sure things "just work”.
> 
> And I think everybody really appreciates this and is VErY happy about it. This is essential work!
> 
>> It is doable, just a lot of work, so by using Homebrew every user has to spend that time.
> 
> Doable: definitely. lot of work: in my experience not that much more.
> 
> Overall, I definitely agree, that the official distribution should stay the proper apple way. But there are circumstances, where these are delayed, or problems occur after macOS upgrades, which will delay the compilation of new ones (GRASS did not have Mac binaries for a long time due to this problem). 
> 

I'm not sure what you refer to, but if there are issues, please let me know. If you don't report issues, they won't get fixed.


> So an alternative way of installing, community supported but approved, would be preferable. The r formula for homebrew has been installed in the last year more that 112.000 times (https://formulae.brew.sh/formula/r) so I think there is likely a rather large user base of R from homebrew. 
> 
> A first step in this direction, would be to either include homebrew in this list, or create a new R-sig-hoebrew list, which could become the home of these discussions.
> 

I'm not sure I'd like to go there. I would direct that to Homebrew as we have nothing to do with the formulae used there. However, that's not really my call.

Today another reason came up why I have an issue with Homebrew: people install compilers and similar tools and then use them instead of Xcode for everything outside of Homebrew. That is absolutely unsupported, because they have different runtime environments, so things break. Sometimes in subtle ways and things segfault at random points. The thing is, if people knew what they were doing, and Homebrew was only used by developers, it would be all fine - they'd know not to mix and match run-times. But most user don't.


> 
>> 
>> (FWIW I use Hombrew myself for tools, but not in /usr/local (I'm using /opt/brew) and I only put it on the PATH for the tools that I need, never to compile anything "native" against it.)
> 
> Than you are completely in the cold and without support from homebrew… As far as I heard, in this case, everything is locally compiled and not using the binaries - correct?
> 

No, binaries are used where it is safe. There may be a few bottles that don't like to be installed in a custom location. I have not seen issues with it. To be honest I think putting homebrew in /usr/local was a bad mistake as that causes a lot of problems since all 3rd party software installs there, so you get very quickly to completely broken state. As with all those things, it's predicated on full control so if you don't use anything but Homebrew ever it's ok. But pretty much all native open source packages/installers install into /usr/local so the moment you use one thing in addition to Homebrew things start breaking.

Cheers,
Simon


> Cheers, and thanks again for your very useful clarifications,
> 
> Rainer
> 
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> Anyhow, this is also not relating to the initial topic of that thread and should probably discussed separately.
>>> On 2. Apr 2020, 10:04 +0200, Rainer M Krug <Rainer using krugs.de>, wrote:
>>>> I am using Homebrew on a Mac (two Macs - one at home, one at work) instead of the official R package, and I did not have any problems after upgrades - maybe I am lucky, maybe not as picky in defining “problem”, but my suggestion would be to try R from homebrew to install R.
>>>> 
>>>> OK - no support from here - I know.
>>>> 
>>>> And homebrew has also binary versions. What is missing, is a hombrew R package repository. Maybe an idea to create one?
>>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Rainer
>>>> 
>>>> 
>>>>> On 2 Apr 2020, at 02:37, Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>>>>> 
>>>>> On 01/04/2020 2:48 p.m., Carl Witthoft wrote:
>>>>>> If I should ask over at r-sig-debian instead of here, please tell me.
>>>>>> I don't wish to clog r-sig-mac with off-topic stuff.
>>>>>> I've been watching the massive headaches people are dealing with trying
>>>>>> to keep R fully compatible with each MacOS X upgrade, I'm wondering
>>>>>> whether replacing my iMac (2009) with a new Mac really makes sense from
>>>>>> an R - user point of view, as opposed to getting some inexpensive
>>>>>> desktop and installing Linux. I know I can run R and RStudio under
>>>>>> Linux, for example, but don't know what limitations, if any there are
>>>>>> when it comes to building packages from source, getting compatible
>>>>>> compilers, and so on.
>>>>>> What have some of you 'power R users' discovered when/if you tried to
>>>>>> build , or incorporate Bioconductor or other repository's packages under
>>>>>> Linux?
>>>>> 
>>>>> If your iMac is still working, try installing Ubuntu or some other Linux on it. I think at that age Apple is no longer providing upgrades, but I just put Ubuntu on a 2008 iMac, and it works well. (I needed to upgrade the memory, but that just cost $40 for 4 GB.)
>>>>> 
>>>>> So I got a $40 desktop, with a nice screen.
>>>>> 
>>>>> Duncan Murdoch
>>>>> 
>>>>> _______________________________________________
>>>>> R-SIG-Mac mailing list
>>>>> R-SIG-Mac using r-project.org
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>> 
>>>> --
>>>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)
>>>> 
>>>> Orcid ID: 0000-0002-7490-0066
>>>> 
>>>> Department of Evolutionary Biology and Environmental Studies
>>>> University of Zürich
>>>> Office Y34-J-74
>>>> Winterthurerstrasse 190
>>>> 8075 Zürich
>>>> Switzerland
>>>> 
>>>> Office: +41 (0)44 635 47 64
>>>> Cell: +41 (0)78 630 66 57
>>>> email: Rainer.Krug using uzh.ch
>>>> Rainer using krugs.de
>>>> Skype: RMkrug
>>>> 
>>>> PGP: 0x0F52F982
>>>> 
>>>> 
>>>> 
>>>> 
>>>> [[alternative HTML version deleted]]
>>>> 
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac using r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>> 
>>> 	[[alternative HTML version deleted]]
>>> 
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac using r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)
> 
> Orcid ID: 0000-0002-7490-0066
> 
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
> 
> Office:	+41 (0)44 635 47 64
> Cell:       	+41 (0)78 630 66 57
> email:      Rainer.Krug using uzh.ch
> 		Rainer using krugs.de
> Skype:     RMkrug
> 
> PGP: 0x0F52F982
> 
> 
> 
> 
> 	[[alternative HTML version deleted]]
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac