[joshmoz]

Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy.

I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return.

Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.

[msbarnett]

For a while at least, when Homebrew was getting popular, MacPorts seemed highly moribund and destined to be abandoned. It seems to have recovered some life since then, though.

Homebrew got big in the ruby community first -- I distinctly remember trying to get Rails to work with MacPorts' MySQL install and the whole thing turning into a clusterfuck, and then someone introducing me to homebrew where the whole thing just worked smoothly because every other Rails dev was walking the same path.

Homebrew exploded among ruby devs because adding new recipes to it was a couple of orders of magnitude easier (just write a few lines in a simple ruby DSL and send a pull request on Github) than MacPorts (hack about in bash cruft and then, what, open a ticket somewhere with a patch to ask for someone with an SVN commit bit to commit it, I guess?

[teacup50]

Nothing really changed in terms of MacPorts liveliness; development continued as it always had, and Homebrew has gradually learned why MacPorts adopted the solutions it did -- usually the hard way.

Homebrew's popularity was built on incredibly negative (and often dishonest) marketing that painted MacPorts as old and busted.

For example, Homebrew touted the security advantages of not using sudo, as compared to MacPorts, ignoring the fact that:

1) MacPorts dropped privileges when performing port builds to an unprivileged user, providing generally higher security than running with the current user's full permissions.

2) MacPorts has always also supported non-root installations that didn't require sudo.

[briandear]

Dishonest marketing? Really? Homebrew, a free tool was out spreading lies about MacPorts? That's ridiculous. When pretty much every major Ruby shop uses Homebrew, why would I want to kick around with MacPorts? I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using MacPorts. Perhaps Homebrew 'won' in that particular community because it was better, ever considered that? Wide community adoption is a far bigger incentive to use a tool over potentially trivial conceptual disagreements.

[teacup50]

> Dishonest marketing? Really? Homebrew, a free tool was out spreading lies about MacPorts? That's ridiculous.

Ridiculous? Homebrew's marketing tagline was "MacPorts driving you to drink? Try homebrew!". The (obviously uninformed) slams of MacPorts and Fink didn't stop there.

It was the first time I'd ever seen negative marketing against a competing OSS project.

> When pretty much every major Ruby shop uses Homebrew, why would I want to kick around with MacPorts?

That wasn't the case then, was it?

> I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using MacPorts.

Yes, this is the kind of specious negative marketing Homebrew specialized in.

> Perhaps Homebrew 'won' in that particular community because it was better, ever considered that?

Sure, I considered that. Then I objectively reviewed Homebrew's claims.

[shadowmint]

> obviously uninformed...

Perhaps you never didn't use macports or fink a few years back?

They were terrible.

Perhaps, now, they're slightly better, but there was a time about oh... 2 years ago, when macports specifically actually made me want to punch my computer.

I can't speak for anyone else, but I can say, that for me, personally, every complaint leveled against them was absolutely spot on.

[trjordan]

Macports never worked for me. I'm not sure if I'm not smart enough to make it work, but there was always something where updates would fail, or some package was broken.

Homebrew just worked, and when it breaks, brew doctor is typically spot-on in telling me how to fix it. I've never had the time to figure out why MacPorts gave me trouble.

[npongratz]

I'd advise caution doing an `rm -r /opt`, and suggest it might be more precise (and generally better) to `rm -r /opt/local`. Macports will typically install to /opt/local, and in my experience, stuff like vagrant and certain VPN clients will install into subdirectories of /opt.

[mzs]

In fact there was a version of Cisco VPN client that blew away /opt (and all of my macports) on first install!

[rsync]

"Agreed, I don't understand why so many people use homebrew instead of macports."

This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive.

The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.

[mapgrep]

Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)

[Scarbutt]

I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?

[neverpanic]

It can, in theory. In practice, there are some ports that actually need a full Xcode installation to build, and those would just fail without Xcode.

In an ideal world, there would be a dependency declared on Xcode for all those ports so MacPorts would work with command line tools only and fail gracefully whenever Xcode is required. However, that is currently not the case because nobody implemented an easy and automated way to tell whether a port will build fine without Xcode.

[nomel]

Don't many of the dev command line tools, like clang, come from xcode?

[mnem]

The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.

[rsync]

Yes, that's true, and of course that's what I'd like to do (command line tools only), but last time through that was yet another ten minutes to find the correct xcode and match things up and so on ...

I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.

[alayne]

I started using Homebrew when I was a new Mac user because MacPorts didn't work out of the box through the corporate firewall. It's kept working for me so I haven't found a reason to try MacPorts again.