> On 3 Apr 2020, at 13:25, Simon Urbanek <simon.urba...@r-project.org> wrote:
>
> Rainer,
>
>
>> On 3/04/2020, at 10:01 PM, Rainer M Krug <rai...@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.urba...@r-project.org> wrote:
>>>
>>>
>>>
>>>> On 2/04/2020, at 9:15 PM, Patrick Schratz <patrick.schr...@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.
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
>> <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 one is installing. So the questions would
not only cover the “how do I install R” type, but also related to packages in
the follow up, which is definitely not homebrew-list material.
>
> 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.
I definitely think there would be a possibility of adding a r-devel
installation to homebrew for R, which would make it easier for developers to
install R-devel.
>
>
>>
>>>
>>> (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.
That is good to know - maybe I’ll try it out sometime, as I would prefer
homebrew in /opt/brew.
> 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.
I absolutely agree. This created such a mess, as even homebrew casks sometimes
install in /usr/local.
Cheers,
Rainer
>
> 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 <rai...@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.dun...@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@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.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
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac@r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>
>>> _______________________________________________
>>> 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: 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.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 <mailto:R-SIG-Mac@r-project.org>
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> <https://stat.ethz.ch/mailman/listinfo/r-sig-mac>
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> <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.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
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
