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
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.
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..
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.
Giving this a try now. While I'm waiting for XCode to download, can anyone comment on the best way to get Apache httpd running on OSX? Is there a Homebrew package for this?
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.
Ah, I knew that Web Sharing used Apache, but I didn't realize that it was packaged in such a way as to be usable for stuff beyond Web Sharing. The conf files seem to live in /etc.apache2. Thanks for that.
I am intrigued by the overwhelming support for Homebrew here -- is there a web resource for package lists so I can see if it will work for me? I haven't been able to google one up.
I don't use macports a lot, I think the biggest things I have installed are Python 2.7, PIL, and Hg.
Last time I looked, MacPorts had a more paranoid approach to dependencies. That can be good and bad. Homebrew can be easier to use, until you run into a corner case that trips it up. MacPorts can be frustrating in how many dependencies it will insist on installing its own version even though the system-provided version might have worked.
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.
Familiarity in my case -- for my legacy Mac servers I'm sticking with what both I and my boxen know. :) New servers will all be running Linux, so it'll be with the package manager for that distro, likely Debian.
Don't care. Switched to Homebrew. Much happier - no double-installs unless I want to, faster fixes, and waaaaay faster interaction. How MacPorts manages to run so slowly is beyond me.
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).
New Mac user here (~5+ weeks). Just echoing what others have said about Homebrew here so far:
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.
As a point of contrast - I've been using OS X for about 8 weeks and I had some problems when first installing Homebrew (I do not remember the specifics, but I seem to recall some issues with installing iPython and the modules I wanted to use) - and since giving MacPorts a try I've really had no issues with it.
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).
Congrats to the MacPorts team for 2.0 and lion support. It's unusual in a HN thread that most of the talk is about an alternative to the posted topic. However, I have to tip my hat to the work the MP team but it would be irresponsible to recommend it over Homebrew. Homebrew is what a package manager should feel like.
