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
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?
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.
2) Brew packages are simple to make and inspect. Many people make and inspect them. Bug fixes happen quickly.
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..
Confirming that - my new MacPorts 2 install installed perl and ncurses just to get ipython.
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.
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.
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.
I use Apache to front Tomcat on a linux server, but it would be really handy to be able to test stuff locally on my Mac before copying changes up to the server.
I don't use macports a lot, I think the biggest things I have installed are Python 2.7, PIL, and Hg.
They usually only provide the most recent stable version of each project but you can find other formulas on the web and just run:
brew install [url]
I've gone back and forth. For a while homebrew could install a working GHC for me while I wasn't having any luck with MacPorts. Later something else caused me to switch back to MacPorts. Neither is perfect. Even MacPorts only allows dependencies at the package level, without regard to variants, or versions, if I recall correctly.
I just want it to install packages. It does that so I'm happy.
MacPorts has been annoying since day one, but it worked where there was nothing else truly competitive (Fink? Everything bad in MP, plus even slower updates. Only benefit is the sometimes-functional binary installs). Now we have Homebrew, and it's way better, if it has fewer legacy recipes (though not always).
To upgrade, make sure you install Xcode 4.1 via the App Store (free). That'll provide GCC. After:
$ sudo port selfupdate
$ sudo port upgrade outdated
After some research, MacPorts looked painful to install/maintain so I went with Homebrew seeing as it looked like there was more activity going on there as well as being easy to contribute to via github and what looked like a short tutorial on creating and contributing your own packages (+ a bit of ruby knowledge) if I felt the need.
I like it simple. :)
My only advice on MacPorts is to always do a dry-run before installing packages (port -y install), to see what dependencies will be dragged in - installing num.py wanted to re-compile a numerical computing package from scratch which I had to kill after a few hours of compilation (with no visible progress on the command line).
After "debugging"-it, e.g: port -v self update
it gave me some mysterious problem of SQLite missing 64-bit version from... /Library/Mono.Framework/.../sqlite.dylib - don't remember the details.
Found some notes how to uninstall mono from their site (little script), and then "port selfupdate" went fine.