I'm just migrating from Ubuntu Linux to Mac, and everything is new and I'm re-learning a lot of stuff.

On Linux I had the excellent apt-get to manage software packages. I googled for an alternative on Mac and found about MacPorts, Fink and Homebrew.

I will use this computer primarily to develop Ruby on Rails applications.

So, what are the differences between them? Which are the upsides and downsides? Which one is best maintained and has more packages?

  • 6
    I edited your title to make it match your real question. On most Stack Exchange sites question asking for "the best" are frowned upon. – Loïc Wolff Dec 1 '11 at 17:15
  • 1
    Why do you need any of these won't ruby's gems be sufficient? – mmmmmm Dec 1 '11 at 17:19
  • for more on why duplicates aren't always bad: apple.stackexchange.com/questions/11461/… also there are a few more alternatives there – cregox Jun 15 '14 at 22:03
  • Never used it myself, but perhaps a comparison to pkgin would also be useful. – Dennis Oct 10 '14 at 15:23

Definitely Homebrew. I started with Fink, then switched to MacPorts (happier), then Homebrew (much, much happier). These are my reasons for using each (a pro list if you will):


  • Apt-based - feel right at home if you come from a Debian-based environment
  • Binary packages - packages are available as binaries so no long compile times. Practically though I've found that the pre-compiled binaries were always outdated and I had to compile stuff for my system anyways
  • Decent selection of packages


  • Biggest selection of packages/ports
  • Generally very up to date
  • Nice variants system that lets you customise the build
  • Easy and intuitive port files, also allows you to add your own
  • supports many versions of OSX and macos going back to Tiger including PowerPC versions see other answer


  • Very up to date
  • Maximum leveraging of what comes with OS X. Unlike Fink or MacPorts, it does not require you to build/install ruby and libraries from scratch just to install some small Ruby-based tool.
  • Installs into /usr/local so does not need you to modify PATH anywhere
  • Everything owned by user, so no packages ever need potentially risky root access to install
  • Every installed package is cleanly sandboxed into its own cellar so you don't have stray files all over your system, just symlinks from bin, man, etc.
  • Ridiculously easy to create your own formula files (ie. package descriptors)
  • Since you're from a ruby background, another plus is everything is written in ruby and all formulas are simple ruby scripts


  • Very up to date
  • Faster installs because of Pre-compiled binaries
  • Everything installed in /opt/pkg/
  • backed by pkgsrc community and Joyent
  • Known to work on NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix



| improve this answer | |
  • 39
    Note that for home-brew you can argue that "Installs into /usr/local " and " leveraging of what comes with OS X" are problems - they are the two main reasons I use another packaging system – mmmmmm Apr 11 '13 at 20:10
  • 5
    Given that /usr/local/bin isn't in the default Mac OS X path, you most certainly do have to modify your PATH—you just only have to do it once, since brew puts in that one place links to all the new bins it installs (except the "keg only's", but that's noise here). – Terry N Mar 19 '14 at 20:24
  • 6
    @jedd.ahyoung I prefer macports which puts in /opt/local (fink puts in /sw) – mmmmmm Jun 10 '15 at 9:58
  • 6
    Unfortunately, homebrew seems to be more & more rejecting certain use-cases & APIs insomuch that the maintainers express a blatant disregard for users. Macports is looking like a better alternative since this trend seems to be pervading homebrew in an unsettling way. Homebrew, at one time, was all about helping the user, but has slowly moved away from that. – GDP2 Apr 17 '18 at 18:17
  • 7
    I have to agree with @GDP2. I am a new Mac user from linux. Developers in brew have very bad attitude. Can you believe there are only 13 issues in brew's github when I am posting this comment? They don't want to listen users. They don't want any issues. They just ignore any issues you opened and closed them immediately. I never see such attitude in any of github projects. As a new user, I have used brew for some months and today I am thinking to switch to another one and found this question. The experience using brew is the worst one I had in my life so far – sgon00 Nov 30 '18 at 9:42


It is more independent of Mac OS X, this means MacPorts will just ignore many of the system libraries and softwares that already available in Mac OS X and pull its own one instead, which could be slower when the utility you install requires some set of large libraries and softwares.

But this kind of choice is safer because the packages you installed are less influenced by Apple's system update/upgrade procedure.


It is more dependent on existing Mac OS X installed packages, so this will speed up the installation of packages and minimize redundant libraries.

But the risk is installed packages might be broken because of Apple's system update/upgrade.

So, these are the two different kind of tradeoff.

Also, Homebrew takes over /usr/local by default, with which some folks don't like this because it somehow conflict with the unix-tradition and might cause problems if you’ve already installed anything there (MySQL, etc.)

Apart from these differences, considering the packages these two can offer, you can check with these two commands if you already have MacPorts/Homebrew installed, which show you the packages they currently provided:

port list | wc -l
brew search | wc -l

And you will find out that MacPorts has many more packages than Homebrew.

(19399 v.s 3583 on May 13 2016)

| improve this answer | |
  • 19
    As a remark on the differing number of packages: Homebrew decidedly does not include packages for programming languages which have their own packaging system (rubygems/pip/cpan…) or for software for which an arguably more appropriate OS X installer is available (MacTeX). Also, duplicates and older versions are not in the default repo but includes in alternate tap repos. Compare this to macports, which, eg contains an IPython port for all included Python versions. It is kind of a different philosophy which naturally increases the number of packages in macports. – Debilski Nov 17 '13 at 12:42
  • 2
    Excellent link! terrychay.com/article/macports-vs-homebrew.shtml Thank you! – Jeff Burdges Oct 19 '14 at 20:51
  • @YaOz, Surely you could change homebrew to use something else other than /usr/local? – Pacerier Nov 1 '17 at 22:03
  • @Pacerier I believe anywhere other than /usr/local/ is “unsupported” or “discouraged”. – Franklin Yu Feb 9 at 4:20

Just to add some of my own thoughts that seem true-ish circa late 2014 at least.

Homebrew, as of a couple of years ago, definitely has the upper hand in terms of mindshare. You'll find a lot of blogs with people talking about how much happier they are with Homebrew - usually because of the whole "MacPorts pulls in the whole world" vs "Homebrew makes use of what you already have" thing.

However, IMO, MacPorts is a different beast now than it was a couple of years ago. When I first switched to OS X & was using MacPorts the MP philosophy was indeed frustrating because almost everything was built from source. A new installation was particularly painful/slow. However over the past year or so, based purely on my own impressions, it seems like 90% of MP packages are binaries & so installation is actually really fast now. From what I gather Homebrew is also moving in this direction with "Bottles" but i get the impression that most things you install via HB at this point in time will be compiled from source.

So, if only to offer a countervailing opinion, MacPorts seems to actually be the "faster " option these days. However most peoples opinions of MP seem to be based on experiences from circa 2011-12 or so & dont really take this into account. Take this with a grain of salt though as I'm not a regular HB user (and its rather painful to use both side by side).

I do think HB has advantages that mean it will probably "win the war" in the long run though

  • HB is all Ruby whereas MacPorts, and its package formulae, are written in TCL which is....not exactly a popular scripting language. That said its pretty damn simple to create your own portfile.
  • HB is based around GitHub & thus seems a lot more welcoming to new contributors whereas MacPorts hosts its own SVN repository somewhere I think - which basically reflects the different ages of both projects I suppose.
  • As mentioned the general consensus is that MacPorts has been superseded by HB &, rightly or wrongly, that draws more people towards it.

Otherwise YaOZl & kLy covered the main difference in terms of sudo, dependencies etc pretty well. Personally I do find that MacPorts sometimes leads to some headaches in terms of other programs not expecting anything to be in /opt/local, things being installed with root permissions etc & there are some things that are generally best not installed with MacPorts (e.g. you can install Rails via MacPorts but you'd be crazy not to install it via Ruby's normal Gem management). Other than that though I'm a big fan of the MacPorts philosophy of building its own little world & not relying on some prepackaged OS X library - when it works, and it mostly does, everything is dead simple. Which is what you want of a Package Manager really. And as i mentioned, at this point in time its pretty damn quick to set most things up.

Hope some of that was useful.

| improve this answer | |
  • 1
    "As mentioned the general consensus is that MacPorts has been superseded by HB &, rightly or wrongly, that draws more people towards it." ... this feels like a very superficial statement... being popular vs providing quality are not the same and by no means imply the second is "superseded" by the first. – Dmitri Zaitsev Jul 30 '19 at 7:33
  • MacPorts is now using Github. See guide.macports.org/#project.github: "The MacPorts project uses the Git distributed version control system to manage the code for the entire project. Our master repositories are hosted on GitHub. We maintain public repositories for almost all our project code and documentation, including a GitHub repository for the MacPorts system itself, for the MacPorts ports, and even for the guide you are reading right now." – Kenston Choi Feb 23 at 11:01

Something which other answers (so far) don't appear to have mentioned is that MacPorts has excellent support for legacy versions of macOS. Homebrew only supports the OS's that are currently supported by Apple, which usually means the last three releases. For example, as of August 2020, only Catalina, Mojave, and High Sierra are compatible with Homebrew.

By contrast, MacPorts can be installed on Tiger (!), and the project maintains special patches to keep software working wherever possible. They also maintain a "Legacy Support" library which backports symbols from new versions of macOS to older ones; linking against this library while compiling can make all sorts of new software suddenly work on older systems!

So, if you're running an old version of macOS, or if you think you may need to stay on a current OS past Apple's expiration date, that's definitely a reason to go with MacPorts.

| improve this answer | |

Brew was completely smooth for me to use, so I'm unable to tell about its cons. Some disadvantages of MacPorts:

There are several very popular questions about the first two points.

| improve this answer | |
  • This was my experience installing ImageMagick on 10.6; brew was very easy, but didn't include the JP2 delegate. imagemagick.org/script/binary-releases.php – Nemo Oct 28 '15 at 10:30
  • 5
    brew and macports just require Xcode command line tools so the same here. – mmmmmm Oct 28 '15 at 11:13
  • @Mark I'm not sure what you mean, but brew worked perfectly for me without Xcode. – Nemo Oct 28 '15 at 11:20
  • 5
    You'll need a complier for brew and MacPorts, which can be installed via the Xcode Command Line Tools. You will not need the Xcode application. – nohillside Oct 28 '15 at 12:44
  • 1
    I forgot how ugly it is to sync that thing when behind a firewall...yikes! – rogerdpack Aug 30 '17 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .