A friend asks whether they should use [MacPorts][MacPorts] or [Homebrew][Homebrew].
What these are, are ways of installing Unix (Linux or BSD) software on your Macintosh in a way that they get updated. This is useful if you need to customize your [(L)AMP][LAMP] stack, or process a document in [LaTeX][TeXShop], or do [graphing visualization][GraphViz] or [-code optimization][KCacheGrind]… there are a lot of uses and having a consistent Linux-like or BSD-like tree of libraries and applications is usually the best option.
I use MacPorts and I’ve used [Fink][Fink] in the past. I never tried Homebrew
[MacPorts]: http://www.macports.org/ “The MacPorts Project”
[Homebrew]: http://mxcl.github.com/homebrew/ “Homebrew: MacPorts driving you to drink? Try Homebrew!”
[Fink]: http://www.finkproject.org/ “Fink”
[LAMP]: http://en.wikipedia.org/wiki/LAMP_(software_bundle) “LAMP (software bundle)—Wikipedia”
[GraphViz]: http://www.graphviz.org/ “Graphviz: Graph Visualization Software”
[KCacheGrind]: http://kcachegrind.sourceforge.net/html/Home.html “KCacheGrind”
[TeXShop]: http://pages.uoregon.edu/koch/texshop/ “TeXShop”
Fink is great. It is based on Debian Linux [apt-get][apt] and has [a nice GUI tool][FinkCommander] for seeing and maintaining packages. The reason I switched was simply because it would take **forever** to install some new software (like kCacheGrind) because the dependencies would be so large and I’d be compiling everything since I needed access to the “unstable” branch for some stuff and only the “stable” branch was available as binaries, and that would often fall out of maintenance (every time a new version of Mac OS X came out). The combination of the two meant that I’d be required to compile, and compile, and compile, and often something would fail in the middle because their package maintenance was spotty (my opinion).
The BSD version of software package management has always been the Ports system, so it was only natural that since Mac OS X is modeled after BSD (via the Darwin kernel) that someone would make Ports for it. That became DarwinPorts, which is now known as MacPorts. I found that compile times are longer for some stuff, but shorter in others because it is much easier to avoid optional packages (via port files). On the other hand package maintenance seemed a little better and failed compiles seem to occur much sooner, than later. Also, there were packages available that were not available or never seemed to work in Fink. All in all it seems a wash since both Fink and MacPorts have complete enough package trees.
It’s hard to evaluate from here whether a switch to Homebrew is worth it. Here are some things that sound attractive about Homebrew.
1. Their website is prettier and more mac-like. Looks to me morale is much better than the other package trees because of it.
2. I like the **idea** of depending on existing Mac OS X installed packages since that will drastically reduce compile times and minimize redundant libraries
3. The [git][Git] repository tied to a [SQLite][SQLite] database is clever. Nothing wrong with CVS and port files, but I appreciate clever. I’m sure if I want to be maintaining my own version from scratch with custom compile files, then this is actually a superior idea. [GitHub][GitHub] being that repository puts everything in the open. I can also see the appeal if you are a Ruby developer since the scripts are in that language.
4. It sounds like Homebrew “formulas” are easier to modify that MacPorts port files if you are noob. The added advantage is you can fork them in Git no problem, whereas your modified MacPorts portfiles will live on an island.
But here is my reasoning for holding back:
1. It’s a younger package tree than MacPorts or Fink. Younger means less packages, and perhaps a package you need is missing. Specifically, Homebrew has less packages than even Fink’s stable tree (not even close to MacPorts or Fink’s unstable tree). This means you’re probably going to have to supplement them with MacPorts or Fink anyway. If not, how tested are these packages? I’m not looking forward to begin someone’s guinea pig.
2. Homebrew takes over /usr/local by default. I don’t like this because you are asked to hand install stuff into /usr/local. There is a long unix-tradition that speaks to this effect. This means you might run into conflicts with stuff you installed by hand, and you can’t reset the entire management tree with a simple command. It also means that on my particular install /usr/local precedes /opt/local (MacPorts) and /sw (Fink) in my path. Guaranteed that a Homebrew software will be always used in precedence to either. While I’m sure you can install it elsewhere I wonder what sort of developers would choose /usr/local, what is the reasoning for a package maintenance system that isn’t defacto standard (like [yum][yum]+[RPM][rpm] on Fedora, apt-get on Debian, Ports on BSD) to decide to go head-to-head with user-maintained software?
3. By default /usr/local gets its perms reset to the user. By convention, /usr/local is supposed to be set so all users of the systems can use it. Clearly the mentality is a single user computer.
3. [/usr/local][usr-local] and “prefer Mac OS X packages” by default is not a new idea, I’d say it is the first idea that pops into any port maintainer’s brain—[Rudix][Rudix] does the same thing, for instance. This sort of thing works great until Apple upgrades their operating system and all your dependencies break. Even if not, you are depending on some drastically old libraries. Apple lags the latest libraries by a noticeable margin—I can’t remember how long they were on PHP 4 and Apache 1 before they switched (did they? I hope so).
4. In fact, MacPorts used to prefer Mac OS X packages by default, [but switched to using their own libraries][MacPorts FAQ]. While I like the *idea* of using existing system libraries, MacPorts did this also and gave up on it. Why? What lessons can be learned here? Nothing is without its tradeoffs, so what are they? My guess is you’re going to find out with Lion. Homebrew came into existence shortly after the previous system update (Snow Leopard), so they’ve never had to deal with the rug being pulled under them. I’ve seen it, and the frustration of the binaries never working is why I (and many others) migrated from Fink to MacPorts.
4. Homebrew formulas have no use-history like apt-get or portfiles. There are historical changes like dealing 32-bit/64-bit binaries, making a default install tree, support for downstream and upstream package dependencies (versioning), handling local changes, conditional compilations, etc. Not sure Homebrew has dealt with them all. I suspect growing pains.
6. I’m a lazy person. I let good enough win over better any day.
In other words, the only thing I find in favor of Hombrew is the only thing I will grant is the decision to use Git/GitHub and SQLite, since those options didn’t exist when the other package systems were invented.
But, all my negatives point to one great reason to avoid Homebrew: attitude. The attitude is “we’re better and here is why” without even a hat tip to why their predecessors opted on a different strategy. Why re-invent the wheel? When you don’t acknowledge your failing (you don’t have to on your homepage, but there should be a healthy discussion **somewhere**), then I am go running. Instead I see a lot of arguments of opinion spun as arguments of fact, that implies that a switch to Homebrew will end up [tasting more like Kool-Aid][Drink the Kool-Aid].
I remember having both Fink and MacPorts around on the same machine for a year, other than redundant files, there were no problems. I’m sure if you can live with Homebrew being the preferred libraries and software, you can install Homebrew and MacPorts at the same time—preferring Homebrew and supplementing it with MacPorts. Maybe I’ll try that if enough of you convince me.
For my friend, I recommend he either uses MacPorts, or installs Homebrew (in a directory like /usr/brew) and supplementing any missing packages with MacPorts (instead of messing with the formulas). If he were a Rails developer, I’d say go all-in with Homebrew. The same things that attracted him to Ruby on Rails will probably attract him to Homebrew. He doesn’t need me to point out the obvious.
[GitHub]: https://github.com/ “GitHub: Secure source code hositng and collaborative development”
[Git]: http://git-scm.com/ “Git: Fast Version Control System”
[SQLite]: http://www.sqlite.org/ “SQLite”
[Rudix]: http://rudix.org/ “Rudix: Unix ports and packages for Mac OS X”
[MacPorts FAQ]: http://trac.macports.org/wiki/FAQ#ownlibs “Why is MacPorts using its own libraries?—MacPorts FAQ”
[usr-local]: http://hivelogic.com/articles/using_usr_local/ “Using /usr/local”
[Drink the Kool-Aid]: http://en.wikipedia.org/wiki/Drinking_the_Kool-Aid “Drinking the Kool-Aid—Wikipedia”
[yum]: http://yum.baseurl.org/ “YUM: Yellow Dog Updater Modified. Based on a Linux port for MacOS (pre-Intel) days called Yellow Dog Linux”
[rpm]: http://en.wikipedia.org/wiki/RPM_Package_Manager “RPM Package Manager—Wikipedia. Red Hat’s copy of slackware’s system. Very popular management in the Unix world when paired with yum”
[apt]: http://en.wikipedia.org/wiki/Advanced_Packaging_Tool “Advanced Packaging Tool—Wikipedia. Single-handedly responsible for the popularity of Debian Linux, IMO.”
[FinkCommander]: http://finkcommander.sourceforge.net/ “FinkCommander”