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

[Rainer Krug]

> On 3 Apr 2020, at 13:25, Simon Urbanek  wrote:
> 
> Rainer,
> 
> 
>> On 3/04/2020, at 10:01 PM, Rainer M Krug  wrote:
>> 
>> Thanks a lot for your detailed response - it is very much appreciated.
>> 
>>> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
>>> 
>>> 
>>> 
 On 2/04/2020, at 9:15 PM, Patrick Schratz  
 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.

My question would be: how? Is the installation from binary forced when 
installing with that option?

> 
> 
>> 
>>> 
>>> 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.


No problems here - this was just an example, where a second "approved” 
(whatever that means) installation approach would be useful.


> 
> 
>> 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.


At homebrew, you have to get hold of the maintainer of that formula - which is 
often not that easy. Power user problems of a software can only be solved by a 
power user of that software - and writing a formula for homebrew, only requires 
a basic understanding of the program 

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

[Simon Urbanek]

Rainer,


> On 3/04/2020, at 10:01 PM, Rainer M Krug  wrote:
> 
> Thanks a lot for your detailed response - it is very much appreciated.
> 
>> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
>> 
>> 
>> 
>>> On 2/04/2020, at 9:15 PM, Patrick Schratz  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.)
> 
> 

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

[Rainer M Krug]

Thanks a lot for your detailed response - it is very much appreciated.

> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
> 
> 
> 
>> On 2/04/2020, at 9:15 PM, Patrick Schratz  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?


> 
> 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). 

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.


> 
> (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?

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 , 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  wrote:
 
 On 01/04/2020 2:48 p.m., Carl Witthoft 

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

[Simon Urbanek]

> On 2/04/2020, at 9:15 PM, Patrick Schratz  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).

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. Majority of our time as CRAN 
maintainers for the binary releases is about providing dependent libraries for 
packages and making sure things "just work". It is doable, just a lot of work, 
so by using Homebrew every user has to spend that time.

(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.)

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 , 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  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@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: -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.k...@uzh.ch
>> rai...@krugs.de
>> Skype: RMkrug
>> 
>> PGP: 0x0F52F982
>> 
>> 
>> 
>> 
>> [[alternative HTML version deleted]]
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>>