Hacker News Reader

Comment by tomphoolery | Hacker News Reader

IMHO, Homebrew offers a lot of advantages over traditional package management tools. It's simple to use, offers a really easy way to add your own packages, and contributing upstream is quite painless. MacPorts has always been reminiscent (to me, anyways) of the FreeBSD Ports Collection...it might even be based on it I'm not sure. So this seems like a prelude to a possible sunsetting of the MacPorts project in favor of simply using FreeBSD's package management tools on OS X. Not sure it's going to draw me away from using Homebrew just yet, but it's nice to know that there's a continuing effort to have OS X be a part of the UNIX-like OS community.

(fake edit: it's been a LONG time since I've used FreeBSD. feel free to chime in about how wrong I am regarding the ease of adding ports on your own private or public server if things have changed)

View on HN

I've stayed away from Homebrew because of its insistence on taking over /usr/local. I understand the reasoning, but I use /usr/local for my own installs and Homebrew doesn't play nicely in that kind of mixed environment. I would use it if it defaulted to /opt/homebrew or something similar.

I'm looking forward to this new package manager alternative.

Isn't there a way to have Homebrew monitor a "make install" operation so that Homebrew can manage (or at least be aware of) your own installs?

Possibly. I'll check it out again when I have a chance. Perhaps there have been improvements in the past year.

You can install Homebrew in a different place if you want. I have an install inside my home directory.

How does it work in practice? I tried it about a year ago and it still stomped on /usr/local for some packages. If I remember correctly, that was due in part to the package not making it easy to install elsewhere, but Homebrew didn't handle it well.

It always worked fine for me. /usr/local is not even writable by the user I normally use, so it would have caused an error if Homebrew tried writing there - which it didn't. If you're seeing issues when installing to alternate locations, file a bug report.

It definitely shouldn't do that. Most likely that's a fault with the way the formula or Makefile is written, like hardcoding `/usr/local` instead of using $PREFIX.

I used MacPorts for years and eventually gave up and abandoned it for Homebrew. It simply became too common that I would come across a project which had directions for setting things up with Homebrew and when I went to try to do it using MacPorts a required package would be missing, outdated, or broken.

I think the world sort of moved on from MacPorts and honestly I think it's a few years too late for big OpenSource package system to come to Mac OS. I think that Apple is on a long term course that excludes (or perhaps confines or quarantines) Open Source. I also think that package management is really behind the curve in a computer science sense and a 'next, next-generation package manager' needs to come about.

I don't think MacPorts is a direct derivative of the FreeBSD Ports Collection (someone can correct me if I'm wrong), but it's definitely inspired by FreeBSD Ports-- one of the original MacPorts coauthors (Jordan Hubbard) was the original developer of FreeBSD Ports.

I won't be switching anytime soon, though. I moved to Homebrew a long time ago and haven't looked back-- MacPorts feels opaque and isolated in comparison.

>MacPorts feels opaque and isolated in comparison

What does this even mean? If it means "uncool" then, yeah, I get it.

If you are comfortable with Ruby, then it is easier to build packages for Homebrew, and since it isn't centrally managed like MacPorts, things generally get packaged quicker for Homebrew. On the other hand, MacPorts has a long track record and has generally been bombproof for me across 3 or 4 OS updates now.

As an existing MacPorts user, I looked at it from the standpoint of "what is this doing for me that MacPorts doesn't?" I didn't see anything that seemed compelling enough to switch.

I switched to Homebrew a long time ago, when MacPorts had a large advantage in number of packages, freshness, stability etc.

For me, MacPorts' main mistake was to go all in with the "storage is cheap, CPU is cheap" canard just as everyone was abandoning desktops for laptops. MacPorts decided to build its own copy of almost everything that the OS distribution provides, to avoid having to deal with version differences between OS X releases. That might have been a decent tradeoff on a Mac Pro, but when you have a laptop with a small HD (and, later, an even smaller SSD), it is a real issue to have to permanently waste several GB on duplicate copies of Perl, Python etc. just because you want to build the GIMP; to say nothing of the hours it would take to build them.

Homebrew's big selling point, for me, was that it could just use the libraries that already came with OS X.

> to say nothing of the hours it would take to build them.

FWIW, nowadays (for a few years?) macports has binary packages, so that is not as big an issue as it used to be, i.e. installing ImageMagick would take hours, now it just usually gets all of the packages and dependencies as binaries.

I think used space is not a huge problem either (I have 130 packages and it uses 1GB), the real issue is that it's anti-intuitive that macports does not remove inactive stuff and does not autoclean, so you end up with a lot of wasted space for stuff you had no interest in keeping.

Reply on news.ycombinator.com