apple_unix_ad

Why Homebrew?

Apple Unix Ad

Jason Storz, a principal consultant at Redstone Content Solutions asked a great question on Twitter:

This was a question that I started to answer with a bit of history behind it. Some of the history is rather dull, but it does get to why I like using Homebrew as a package manager over the other alternatives.

Way back when, many of us started replacing dual Windows/Linux machines with OS X boxes. (Mine was the ultra-sleek Titanium PowerBook. It could support a full 1 GB of RAM!) The one thing that was missing was a good UNIX (well, or really “Linux”) style package management tool. Enter the Fink project which was the first management tool in the style of the Debian apt-get package manager. Fink was very cool, with one major flaw at the time: Fink packages were binary. While they worked like a champ, the rapid pace of OS X development in the early 2000s made binary compatibility something of a fool’s errand. When Apple released new versions of OS X, Fink would often lag a few months behind in supporting the new version. Not that this was the fault of the maintainers of Fink, it arose from the problem that Apple simply didn’t care enough about UNIX users to be concerned with binary compatibility. The developer community was pushed and shoved by the platform a few times – most notably in the Intel transition and the concept of the “Universal Binary”. Open source package management outside of tight communication with Apple was nearly impossible. (It should be noted that this situation has likely changed as OS X has become more mature – the internals are no longer the Wild West of binary incompatibilities and API changes.)

Some of the developers behind the Darwin project noted the problem and created a package manager similar to the BSD “ports” system initially called “Darwin Ports”, now MacPorts. MacPorts did (and still does) have the advantage of working a little more closely with core “Darwin” (and OS X) developers, but MacPorts does put a little distance between the version of OS X and the capabilities that MacPorts can provide. MacPorts does this by building a separate dependency tree that the ‘typical’ OS X tools, or the need to install Xcode or the Apple Developer tools.

(Everything is placed in /opt/local, and dependencies between the system packages and the Ports tree are minimal, if entirely non-existant.)

What I found in practice: my /opt/local/ directory grew to insane proportions and if I upgraded OS X (or even moved to a new machine like happened a few times), I was starting completely from scratch. There was also a lag between OS releases and a new “Ports” release, and the occasional incompatibilities between ports that would give you very odd build errors.

Enter Homebrew, designed around two principles that make package management vastly simpler (IMO):

  1. Creating a Homebrew package is very simple. All you need is a little working knowledge of Ruby and the Ruby gem packaging system and you can create a Homebrew package. This has been pretty handy as I’ve been doing a little more work with Ruby and Puppet lately – it’s more likely that Homebrew packages will be up to date and functional.
  2. Homebrew works with OS X as much as it can – no ‘external’ dependencies for compilers or build tools; it uses Xcode for build dependencies which helps ensure that there will be some compatibility between Homebrew packages and the host OS.
  3. Homebrew is in essence a simple wrapper behind the UNIX configure, make, make install processes. Nothing requires binary capability, and external libraries required in the dependency tree are also built in the same way. Troubleshooting issues with Homebrew compilations and dependencies has been (IMO) much easier. Homebrew is also very self-contained, you can remove packages and items that Homebrew has installed without compromising the integrity of your system. (At least that I’ve encountered.)

(NOTE: Homebrew does ‘bottle’ some software to be installed as a binary for stable libraries, but it does offer you the choice on install to use binaries where it makes sense. See the Homebrew FAQ for more detail.)

In essence, I’ve grabbed onto Homebrew as a package manager primarily because it works with less frustration than Fink or MacPorts did. This might be different in 2013, but it’s been a long road getting here and Homebrew “just works” for me.

  • kalail610

    Interesting read. I wonder what your thoughts are on the future of package management.

    • chad_thompson

      Wow – that’s a tough question. I can probably make a few pretty obvious predictions:

      1) There won’t be anywhere near the changes in package management for the OS X Unix layer that there have been in the past. Apple is no longer positioning OS X in terms of being a “Unix box”

      2) There seems to be some pretty big momentum behind the Homebrew ecosphere. Players like GitHub (http://boxen.github.com) are using Homebrew widely for OS X package management.

      3) Apple is very content to leave the problem of UNIX package management to the open source community rather than promote “the” way for package management. The downside of this is that UNIX packages installed by default in OS X are still a major pain to upgrade and work around. (e.g. upgrading PHP on OS X) Most developers I know (myself included) have found that it’s easier to use Vagrant and Linux VMs for doing server-side development on OS X. I imagine that virtualization and a de-emphasis on OS X as a primary server OS will make virtualization the path for server side (UNIX) development for many.

  • http://henriquegontijo.tumblr.com/ Henrique

    Great and succinct explanation.
    Note: Regarding MacPorts site, where they say “MacPorts is developed on Mac OS X, though it is designed to be portable so it can work on other Unix-like systems, especially those descended from the Berkeley Software Distribution (BSD).”
    Although MacPorts was built to be portable, it stills requires Apple tools (XCode and Apple’s Command Line Developer Tools) in order to be installed on Mac OS X (http://www.macports.org/install.php).