I made the switch to homebrew fairly recently (within the last two months).

Things I like:

* I install everything to ~/.brew/ and it works great. I did _not_ like their documented recommendation to install everything to /usr/local and chown it as your user. I have yet to run into any issues installing to my home dir.

* Installs of things have fewer deps, or at least perceived, compared to macports. Nice to not have a separate copy of everything. I haven't run into issues (yet!) where an OS update makes something puke, so this could be a problem down the road, but so far so good.

* Upgrades are very simple: brew update / brew upgrade

* Toolset is easy to work with.

* timely updates

I'd go for sheer package numbers, and also MacPorts traditionally has had much better support for Python packages, and the rudimentary python_select.

Macports says they have 8199 packages. Brew has 1626 by my unscientific count (hint: $('table.tree-browser tr').length ).

A major difference is in how packages are installed. Brew by default will use native OS X packages. Macports installs all dependencies to /opt/local. So a trivial install for Brew could lead to a long install in Macports. I've had Macports build GCC.

But this new version is supposed to allow for pre-compiled binaries. So maybe a lot of that beef will disappear?

Maybe things have changed but I switched from MacPorts to homebrew in the early days of homebrew (2009?) because it was way easier to install.

MacPort's package installer tools mystified me. Homebrew could be improved too, but is better.

Finally, homebrew seems more open to contributions and because they use GitHub, it's very easy to contribute new packages and the high level of activity on Homebrew reflects that. I briefly looked at what it would take to contribute to MacPorts and it was harder.

1) Brew doesn't hide my stuff in /opt/macports/opt/package/ports/port/python/etc/etc/etc

2) Brew packages are simple to make and inspect. Many people make and inspect them. Bug fixes happen quickly.

Agreed with (2).

I actively create patches and submit it to them whenever I run into a problem, and I will keep doing so, because it's typically only a few days until it gets merged.

How I got into it, was the nifty searching of Github issues that Homebrew does for existing issues when you have a compilation error. One way to get people to report bugs is to show them you care..

Homebrew tries to reuse system packages as much as possible. MacPorts comes with its own everything.

Homebrew tends to have fresher packages---new versions of popular packages are usually updated within hours.

Haven't look back to MacPorts since switched to Homebrew two years ago.

Brew doesn't install the whole universe and take hours to install a small utility. MacPorts does.

> Brew doesn't install the whole universe and take hours to install a small utility. MacPorts does.

Confirming that - my new MacPorts 2 install installed perl and ncurses just to get ipython.

And, even worse, xorg and xdmcp to get py25-pil.

Does brew compile from source? That is one of the most frustrating aspects of macports, for example I was trying to install a simple musical ear training tool the other day and it went to compile GCC. Argh!

The thing with MacPorts is, basically, you're installing a parallel universe that doesn't know about the software your system already had. So it has to bootstrap completely from scratch, including its own toolchain, basic libraries, etc.

Once you get all that, it goes faster, but the first time you go to install something simple you're basically going to walk away for a couple hours while it sets up its own little world.

Yes, in most cases, but most packages have minimal dependencies due to Homebrew's "use what OS X provides" philosophy, i.e., the XCode toolchain (Homebrew doesn't even have a package for GCC).

The benefit is that Homebrew uses what you already have in the system, without creating its own separate world where it rebuilds everything even if a perfectly working version is already provided.

MacPorts used to do this, and then stopped because the copy on the system sometimes wasn't "a perfectly working version" and by virtue of being tied to an entire OS update caused giant incompatibilities (as you had to deal with, simultaneously, broken old versions and broken new versions existing in the ecosystem).

Well, either those are corner cases or the Homebrew guys are doing a great job because I've never had a problem. Not a heavy user though. Before Homebrew I used to build my own packages because I tried and couldn't stand Fink or MacPorts.

I think Homebrew has been around for about two years now; it came out during the Mac OS 10.5 era. That means that only last week has it even gone through a second major release of the OS.

MacPorts, formally DarwinPorts, has been around for nine years, and has been post-1.0 for the last six. I am pretty certain that it came out during the Mac OS 10.1 era, and at the time supported down to 10.0.

Given this stark contrast, to compare the compatibility complexity experience of MacPorts to Homebrew with the statement "I've never had a problem" is nothing less than hubris.

Seriously, the history of every package management system (including such stalwarts as RPM, APT, MacPorts, and even rubygems) is the same: they start off with the attitude "why is this so complex" and then get to find out over the next decade exactly why those things are so complex.

Honestly: why does it matter oh so very much to everyone that you have to rebuild a few more packages? Isn't this just a problem of not having binary packages? If so, rather than sit around and build Homebrew, someone should have just contributed some bandwidth back to Fink.