[R-SIG-Mac] package management system: Fink vs MacPorts?

[Christian Kleiber]

Simon,

just to clarify: I always use the CRAN binaries, now also your 64-bit  
builds. So I infer that package managers are nowadays best avoided on  
Mac OS. I used Fink for non-R stuff, installing subversion etc, but  
apparently that can be avoided too. I was also unaware of Homebrew but  
then I prefer wine themes myself.

Thanks to all respondents,
Christian


Quoting Simon Urbanek <simon.urbanek at r-project.org>:

> Seth,
>
> On Oct 12, 2009, at 12:18 , Seth Falcon wrote:
>
>> Hi Christian,
>>
>> Unless you are doing development with R I would second Simon's
>> suggestion to use the pre-packaged R binary.
>>
>
> Just to clarify -- I wasn't questioning building R from sources -- I
> was questioning why anyone would use Fink or MacPorts R binary since
> you lose the advantage of control over the build and yet you get a much
> more limited binary than the one from CRAN and you can't use CRAN
> package binaries, either.
>
>
>> On Mon, Oct 12, 2009 at 6:10 AM, Christian Kleiber
>> <Christian.Kleiber at unibas.ch> wrote:
>>> I am familiar with building R packages but I have never built R
>>> from source (this might change, however). Question: any strong
>>> opinions re Fink vs MacPorts? Or other solutions? (I have been using
>>> Fink on my laptop for some time without problems but then I never built R
>>> from source.)
>>
>> I have had better experiences with MacPorts vs Fink, although both
>> have a tendency to pull in large sets of dependencies for libraries
>> and tools that are already on your Mac.
>>
>> Recently, I've been using Homebrew [1] as an alternative.  Yes, it is
>> yet another package manager.  One of its aims is to avoid duplicating
>> libs that are already on a modern Mac.
>>
>
> Thank, Seth, I really like the Homebrew approach -- the real problem
> with MacPorts/Fink is that they mess up the system (if you use them) so
> Homebrew takes that out of the equation. I'll test it for a bit and see
> if we can even recommended that since it complements the binaries we
> provide ...
>
> Thanks,
> Simon