Comment by telemachos | Hacker News Reader

Comment by telemachos | Hacker News Reader

Parent Full thread

Explain to me a pain point of Macports that Homebrew solves

It doesn't require you to install a second, shadow Perl, Python or Ruby in order to install other packages. Instead Homebrew uses the Perl, Python and Ruby that OSX already provides. (This may be a con, depending on what you think of Apple's treatment of those packages. I grant that.)

I found the Python issue to be a particular pain in the ass, since MacPorts's Python build requires tk, which requires some GUI libraries, which ends up building more or less an entire X11 sub-system on OSX that I will never ever use.

I ran into this when trying to install Getmail. My solution then was simply to download Getmail and install it the old-fashioned way. I was a little surprised that Getmail built so easily using the system's built-in Python. My first thought was, "If I can do it that easily, using what I already have, why does MacPorts force me to download and build all this other crap?"

What annoys me about MacPorts (which I love in many ways, don't get me wrong) is that it is not easy to customize builds. You can edit the portfile easily enough, but every update undoes that.

It doesn't require you to install a second, shadow Perl, Python or Ruby in order to install other packages. Instead Homebrew uses the Perl, Python and Ruby that OSX already provides. (This may be a con, depending on what you think of Apple's treatment of those packages. I grant that.)

There are certain things that just don't work right when using the Apple provided interpreters for particular languages, even if the versions are right. Though I don't recall anymore what the specific problem was, I recall needing to install a custom build of PHP to get a particular library I depended on to work. I wish I could remember more of the details. The point is that I can understand a modest amount of distrust for the built-ins.

There's also the matter that the internal versions of the interpreters run the risk of becoming dated, staying that way, and perhaps becoming so dated that the needed code can't run without later version of the interpreter than the OS provides. Discovering whether it is "too dated" sounds like a fragile process, you'd have to either parse the interpreter version or make assumptions based on OS version.

The solutions I see available are: to leave it up to the user to figure out if a newer interpreter is needed, or just assume the internal interpreter won't work and build your own that you're much more certain will work. This comes down to a matter of philosophy, where MacPorts says "we'll figure it out", and Homebrew says "we trust you know what you are doing."

I found the Python issue to be a particular pain in the ass, since MacPorts's Python build requires tk, which requires some GUI libraries, which ends up building more or less an entire X11 sub-system on OSX that I will never ever use.

This seems like more of a criticism for the python port maintainer than the entire build system. It might be worth posting a request for Tk support to be made a variant of each of the python ports.

This seems like more of a criticism for the python port maintainer than the entire build system. It might be worth posting a request for Tk support to be made a variant of each of the python ports.

For the record, I use MacPorts over Homebrew for many of the reasons on this thread. I've been responding to people saying "What's the point?" because I see some of the benefits of Homebrew, even if I'm not fully convinced. (I suppose that I'm also frustrated at the common interwebs reaction of "But I use some other thing, so this new thing must suck." Homebrew may not be the answer to everything, but it's very worth looking at. There are some very good ideas there to some common problems.)

Having said that, my complaint about Python was explicitly specific to that package. That's why I said "the Python issue to be a particular pain..."

The Tk & Python issue has been brought up repeatedly on MacPorts lists and posts about MacPorts. They seem to prefer it that way, and for all I know, they have good overall reasons. Follow-up: Well, I haven't checked in a while, and I'm dead wrong. The getmail package currently depends on Python 2.6, which now does have a no-tkinter variant. Shows what I know.

Edit: By the way, the PHP on OSX is notoriously light on modules. There have also been a few pretty ugly issues with Perl and core modules. So I'm not denying that there are real reasons to worry about the built-ins. I said as much in my post above. There are pros and cons to each approach.

Reply on news.ycombinator.com