A friend asks whether they should use MacPorts or Homebrew.
What they 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 stack, or process a document in LaTeX, or do graphing visualization or -code optimization… 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 in the past. I never tried Homebrew.
Fink is great. It is based on Debian Linux apt-get and has a nice GUI tool 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.
- Their website is prettier and more mac-like. Looks to me morale is much better than the other package trees because of it. 🙂
- I like the idea of depending on existing Mac OS X installed packages since that will drastically reduce compile times and minimize redundant libraries
- The git repository tied to a 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 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.
- 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:
- 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.
- 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+RPM on Fedora, apt-get on Debian, Ports on BSD) to decide to go head-to-head with user-maintained software?
- 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.
- /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 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).
- In fact, MacPorts used to prefer Mac OS X packages by default, but switched to using their own libraries. 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.
- 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.
- 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 running away. 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.
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.
thank you terry!!
Who writes an article comparing two package managers without having used both of them. This is trash-writing and just litters the web. Thanks for wasting my time.
I noticed that number one reply on Quora for the same question recommends Homebrew without the recommender having used either Fink or MacPorts and without any reasoning why, and I’ll bet hypocritical assholes like you upvoted it.
In the article, I recommended that the person can use either MacPorts and Homebrew equally, and gave a few specific examples where Homebrew is definitely the better choice. I also explained some consequences (and kudos) of Homebrow’s design decisions based on their own advertorials on the website. That’s all pretty generous compared to most. You act like I went in and defecated in your church. May I suggest converting to a real religion instead of making a religion over a software install tool?
In any case, since this time, I’ve used Homebrew because nowadays they have formulas that are simply not available on MacPorts. I’m still not a fan (for exactly the above reasons) despite having (and continuing) to use it mostly for the same reasons — for instance, I install it in my home directory only. However I’ll admit the use of Git was a key point in its survival and continued popularity.
(It still lags MacPorts in total package count, however they seem to have quicker turnaround on some packages because there are more effective maintainers due to familiarity with Github for the current generation of developers.)
You criticisms (both pro and con) were fair and you didn’t need to install use Homebrew to make them. I find the most valuable critical review not only detail their conclusions but detail their analysis so I can understand the judgements. Some people would rather see reviews more like Rotten Tomatoes movie reviews: judgmental, biased, inscrutable, and terse. Not me. Thank you
Package management options are just not all that great in OS X compared to its cousin OSes. I do prefer MacPorts over Fink, since as you say, MacPorts seems to have the edge in package maintenance & availability. Though the difference is not huge.
I don’t understand the love for Homebrew at all. I could live with the arrogance & trash-talking about the older package managers if Homebrew actually was a major leap forward. But blindly depending on system Perl, system Python, etc. is a serious design flaw, not a feature to be bragging about. Ditto for taking over /usr/local. I’ve seen Homebrew fanboys advocating doing things to your UNIX system that would just make your jaw drop. Do not want.
I find the arrogance of taking over /usr/local and changing permissions to single-user intolerable in a tool set I would use.
This reminded me to update my install. I hadn’t done so in so long, I had to do a
port upgrade outdated… :pThanks for your assessment, Terry. I’ve resisted the installers (MacPorts & Homebrew) for over a year, building my own versions of utilities as necessary, but I’m considering ease-of-use these days and had a tough time weighing my options.
Thanks again!
Reason 6 above for holding back is a big one in my opinion. Homebrew works fine for installing a bunch of packages, each with a couple of dependencies which in turn have another few dependencies. But before you know it you have some 50-60 ‘formulae’ installed. There comes a point when you want to get rid of one or more of you earlier packages, so you issue a “brew uninstall pkg” and it’s gone. Now you’re left with all it’s (sub)dependencies still installed, which could very well also be dependencies of other packages, but maybe not. Your only option is manually removing each and every dependency, or writing yourself a crude script to test out all the possible connections — something that would become really inefficient if you have a lot of stuff installed.
I’m sure the homebrew developers are looking for ways to solve this problem elegantly and smartly, but for now this could be a good reason to steer clear of homebrew for the time being.
You left out pkgsrc (http://www.pkgsrc.org)
I run homebrew and pkgsrc (together) because they allow me to install what I want without needing to be a privileged user. HomeBrew is pretty restrictive as to what they allow in. Pkgsrc is much more liberal being that it’s the main mechanism for installing third party software on NetBSD and a few other systems. My instructions for getting them to play nicely together are on my blog at: http://www.notadiscussion.com/2011/06/pkgsrc-alogside-homebrew.html
My reasons for avoiding HomeBrew are similar to Evan Goer’s above. In addition, I find the macports world similar enough to my ubuntu/mint/centos environments that i can do roughly the same tasks on all of them. That said, this is a very helpful comment, for several reasons. It reminds us about pkgsrc and even gives a helpful instruction.
Also, I really considered not installing macports and only depending on homebrew on my laptop, which has a small SSD and lots of stuff and is always hurting for disk space. If space is an issue ….
I wonder if there’s not an undercurrent of Python vs. Ruby going on, as well. With Python people preferring MacPorts and Ruby people preferring HomeBrew. It’d be interesting to get polling on that aspect.
That’s interesting and very possible.
I’m a PHP user over Python and Ruby, but that doesn’t make me unbiased. I’m probably pretty biased toward the Python camp over the Ruby camp, right down to my preference toward Puppet over Chef even though both are written in Ruby.
I do think that for many things Homebrew is starting to outpace the other package management tools now, many years later. Though, to be honest, on my computer I’m more task-oriented on my Mac so I prefer a double-clickable installer package to having an entire tree whenever possible. If I want a tree, I use Vagrant (written in Ruby) to create a virtual machine with it or having it on a server. The mentality of my personal machine as a server and a constellation of tools is unappealing to this old man. 😀
I have been using macports for a long time and every time I want to be destructive, I can trash /opt/local and nothing’s hurt. /usr/local is not a good idea. fink was good about 5 years ago. 🙂
What a good blog post. I am just starting out with package managers on OSX, I have friends who are ‘Brew fans and an old School-er Mac user who swears by MacPorts. I have been getting to grips with Macports Your blog has broken down a few barriers for me and along with the comments it is good to have some opinions on why ‘Brew is not the way to go!
I’ve been using MacPorts in my $HOME for one year without any problem. No root, no mess.
This is still relevant – I ran into this today. When I installed Homebrew a couple of years ago, I wasn’t familiar with Git at all – and I ran into an issue with Brew not finding the correct Ruby installation. I edited the brew.rb file to point to the right executable, and happily forgot about it. Down the line, brew update never works – it depends on git and some other system dependencies. Today, I finally decided to try to fix it all, only to realize that it takes over my /usr/local directory! Brew, that directory doesn’t belong to you! I had to manually uninstall the thing, while working around other directories in there (like ClamXAV). Homebrew is nice, but I don’t like what it does to my system. I think I might reinstall it under my home directory and see if I can get it working from there. If that doesn’t work, I’m giving MacPorts a try.
I can’t believe it took over that directory – I can’t believe that it has a GIT REPOSITORY in that directory. That’s just irresponsible.
It is an interesting read even in 2015. However, I am using both Homebrew and MacPorts. I like MacPorts, but I installed a few Homebrew packages when the correspondent MacPorts package required dozens of more dependencies!
Do you still use MacPorts? If one was to install Homebrew and make sure that it requires you to use “sudo” and use a different directory, how would someone do that?