What's the difference between macports and homebrew?

-

Anyone using a mac for software development has probably run into the need for some gnu/open source software that isn't pre-packaged. One of the great failings of Mac OSX is it's lack of a real package manager. Luckily, users stepped up and built some solutions: Fink, MacPorts, and HomeBrew.

I've never used fink, but I hear it's pretty good. Being also a debian/ubuntu guy, I'm familiar with apt-get so it's probably a decent tool... but having no direct experience with it I can't really comment.

This brings me to the two tools I HAVE used: Macports and HomeBrew. I started off with macports because it was the one that had the packages I was looking for. On advice from folks I was working with (I believe the comment was "why are you still using macports, everyone is using homebrew now"). I downloaded and started using HomeBrew, but frankly, I'm unimpressed.

As far as I can tell, the only reason anyone would use homebrew is if they stumbled across one of the web sites/blog posts with the raving fanboys flipping the bird to all the uneducated macports users. When digging around, I did find this fairly objective blog post which leads me to believe that homebrew is really...not that different. The biggest difference I see is that macports has almost everything I want, whereas homebrew is missing huge quantities of useful software, so I ended up requiring macports anyway.

I like the idea that homebrew will apparently use binary packages in some situations and frankly, I don't understand why that isn't the standard. After all, debian and redhat have been doing this for years and it's much more efficient that wasting your user's time recompiling for a tightly controlled platform. Anyway, my advice is macports works for me, homebrew also works, and they seem to both work together... so it really doesn't matter which one you use, but you'll still need macports anyway because homebrew is missing about 6000 packages that are already in macports.

Comments

Chris Ledet said…
This comment has been removed by the author.
September 20, 2011 at 8:31 AM
Anonymous said…
My solution to this problem is to use a virtual machine with Gentoo Linux for everything Unix-ey that's not included in Mac OS X. I like to keep the Unix portion of my OS X install clean, so I don't run into trouble when upgrading or switching machines.
September 20, 2011 at 4:17 PM
rakhmad's shouts and ramblings said…
Can you give example of one program that does not exist in homebrew? I am a new user of Mac OS X, currently using Homebrew.
September 20, 2011 at 7:32 PM
Kip said…
This comment has been removed by the author.
September 28, 2011 at 8:12 PM
Kip said…
An example of one program that does not exist in homebrew?

Handbrake, the multithreaded DVD to MPEG-4 converter which is available via MacPorts.

It's not exactly an apples to apples comparison due to a large number of sub-packages in MacPorts, but when I do

"port list | wc" versus "brew search | wc"

I get 12,319 packages for MacPorts and 1,764 for homebrew.
September 28, 2011 at 8:16 PM
phillip said…
Binary packages are available in macports since about November 2011. At the time they were only for 10.6, because they hadn't been able to acquire a 10.7 box to run the buildbot. Hopefully they've made some progress on other platforms in the few months since then, but I couldn't find any info on the mailing lists.
March 27, 2012 at 11:13 AM
Anonymous said…
I am beginning to have a similar impression of Homebrew. My issue has been not so much that a package that I was looking for wasn't there but, rather that a package that I found and installed didn't work properly. e.g.:

1) byobu - installs fine via brew but, byobu-config fails and has a dependency error. I found discussion but, no resolution in the homebrew community.

2) rrdtool - I tried to "roll my own" brew package (a homebrew selling point) for smokeping which relies on a perl module installed with rrdtool. There is a rrdtool brew package but, the perl module is not installed. Discussion on the github page for that package revealed that the installation of the perl and ruby modules were unintentionally overlooked but, the issue has not been resolved.

Maybe I have to wait for a slew of dependancies to be installed but, I didn't have these sort of package maintanence issues with MacPorts.

Homebrew seems like a young up and coming alternative but, not ready as a complete replacement.

Keep up the good work though b/c there is a great deal of promise.
June 16, 2012 at 1:11 AM
Anonymous said…
I beg to differ. MacPorts just wont install 'wget' for me. HomeBrew did. IMHO if you want lock stock and barely including all libs and all go go for MacPorts else Brew your own. If you don't mind building your own packages go ahead and get Brew. I also like the way Homebrew symlinks files to the PATH rather add a file directly.
September 8, 2012 at 5:31 AM
Anonymous said…
@anonymous: macports installs into /opt/local and therefore doesn't need to symlink anything, it doesn't clutter up any of your standard os x directories. have you even used it?
September 20, 2012 at 1:16 PM
harold said…
Pretty much agree. The most important difference IMO is that macports creates its own sandbox to play in and manage. Given the lesser degree of user "ownership" over the kernel core when you are working in the OS X world vs linux I think macports has taken the right approach, vs the homebrew one of depending on system libraries and binaries whenever possible. Having used macports on one machine and homebrew on another macports seems to scale better as you bring in more packages and when concerns such as deployment to differing machines and OS updates come into the picture.

Part of the reason Homebrew has much more hype/momentum though is probably because its a Ruby project. OTOH Macports is based around TCL which is hardly a thriving language.
October 24, 2012 at 3:40 AM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u
Read more