I still use MacPorts because it's actually a proper package management system. Homebrew is not, and its limitations started to show a long time ago. The obnoxious assertion that Homebrew should take complete control of /usr/local AND be able to install in there as an unprivileged user is utterly ridiculous. It's just some nonsense that the author cooked up in his own head, contradicting a long history of convention regarding the use of /usr/local.

The maintainers of packages are supposed to port their software to the relevant platform, that's their job, and yes sometimes this takes some work, whereas Homebrew seems to assume that ./configure; make; make install should flawlessly work out of the box for pretty much anything (this is not true). The fact that they actively discourage even trying to install outside of /usr/local is simply laziness (and not in a good way). This is a foolish and naive approach, and pursuing this idealistic, reductive approach for "simplicitly" breaks down very, very quickly. MacPorts is a well behaved, self-contained system, and a well designed one at that. Homebrew just dumps everything into a system directory that it really shouldn't have exclusive rights to in the first place (/usr/local).

Moreover, there is nothing wrong with installing extra compilers, libraries, etc, under /opt/local and having them run alongside the system libraries. Lots of systems have provisions for doing something like this.

Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this.

Homebrew's documentation is terrible. Its terminology is facile and stupid in the way it analogizes everything with beer.

> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid".

I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.

Today, Homebrew does have some major shortcomings. The biggest one that comes to mind for me is the fact that it only seems to consider the dependencies of a package during its initial installation. That is, if A depends on B, installing A will trigger an install of B. However, after that, Homebrew will happily let you uninstall B (thus breaking A) without so much as a warning. Less critically, it doesn't track the fact that it only installed B for the purpose of making A work, so it can't help you clean up the left-behind-dependency cruft from the stuff you've since removed.

I don't disagree with your assertion about the state of Homebrew, but I wanted to point out the `leaves` subcommand.

  brew leaves:
      Show installed formulae that are not dependencies of another installed formula.

I'm not sure if it persists this state or simply calculates it on-the-fly by enumerating your installed formulae. But it does seem like the same data or functionality could be used to prevent your uninstalled-deps scenario.

Hmm... Interesting. I don't think that "brew leaves" truly solves the problem, though, since the list it generates will include explicitly-installed leaves in addition to no-longer-needed dependencies. It can help narrow the list of potential candidates for removal, though, which is nice.

The wheat is mixed with the chaff. Ignoring the jabs at the author and their reasoning the odd way it uses and interacts with /usr/local is worth thinking about. Sometimes challenging conventions is good but sometimes those conventions are there for very good reasons that aren't immediately obvious.

Yes, the single userness of Homebrew became obvious when I inherited a MacBook from someone which also contained some licensed software that couldn't not easily flattened and reinstalled. Homebrew sprays single-user shit all over the place and judging by google searches, there was not a clean way to remove it. I ended-up doing a lot of manual deleting. You couldn't even rf -rm /usr/local/, because Homebrew did not own that directory, my licence-locked software dropped stuff there too for example. Really how hard is it to type sudo?

And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them?

I've been using pkgsrc lately. Binary packages that seem to work out of box and come with launchd configs. It goes into /opt/pkg/, and /opt was always better than /usr/local because of the unix philosophy that its shorter to type.

Anyway, if you like Homebrew's approach to the filesystem, there was a OS you would really like, it was called Microsoft DOS. (It didn't work out in the long run.)

> And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them?

I find 90% of the brew things I install are binaries (they call them "bottles"), and I don't even use brew in /usr/local (where even more binaries are available). Have you used brew recently or is your experience from some time ago?

Well, there's also gentoo ;)

I'd agree. I started using Slackware only in 2001 and installing to /usr/local just seems like the best way to handle application software that isn't required by the system. Since Fink got relatively abandoned, I've been using macports and have not gone back to using Fink. Macports is very useful to me for just able all 3rd party software that is unix-y and exclusively an app. The only thing I use homebrew for is cocoapods. I had a bad experience with homebrew when it first came out using, and I've been leery of it since.

> be able to install in there as an unprivileged user is utterly ridiculous.

this. I'm using homebrew and installing every package as my own user is a security risk. One security mistake in a package can interfere with my main user account's files / other packages / etc.

Other package managers (apt, yum, macports, etc.) install each package as separate users (e.g. Mysql as user 'mysql') to prevent bad packages from 'leaking'.

How is it a security risk?

Let's say the code of something you are running locally has a SQL injection vulnerability that allows someone to run arbitrary code on your machine (let's imagine you are running a local copy of your client's WordPress blog with dozens of plugins you don't know where they came from). When the user you, the intruding code runs as you, with your privileges. When the service runs as a restricted user, that's all access the intruder gets.

Next time you go to a meetup, try to do an nmap on your surroundings.

Anyone taking control of your account can take control of (for example) database you installed, without going via the database's authorization system. Not a huge issue on a laptop, I'd say. But in general - your normal user should be able to modify the binaries you're running without gaining some higher auth level. (for example via sudo)

Without going into the rest of your points, which seem bizarrely furious at a piece of software, nothing about Homebrew forces you to live inside `/usr/local`.

It is recommended, but if you want to run in `/opt/brew` or `~/brew` you'll get a warning some things may not work but that's it. There's no hard block, and the vast majority of core formulae can pour their bottles anywhere.

> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this.

Can you go into this? I have to write an update framework at my job and I want to know as much as possible about it before I start.

I believe "anti-pattern" is a way to assert an opinion by giving it the color of best practice.

> It is a best practice to assert ones opinion by declaring the alternative as an anti-pattern.

> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this.

Remember leftpad!

But that specific incident had nothing to do with using a VCS for packages? He removed left-pad from npms index, the code behind it was still online. Or did you mean more generally in a "single point of failure/removal" sense?

When you have a system where an individual can remove one item in a vast dependency tree where no one has central oversight you create risks like this. This also says a lot about relying on external dependencies like there is no tomorrow, but the point is still valid. I can imagine a thousand ways to break a system like this.

Apart from that, version control systems are optimized for controlling versions, not delivering static content.

Can I ask, what specifically do you find to be an anti-pattern about this?

http://qz.com/646467/how-one-programmer-broke-the-internet-b... is a good starting point.

I sincerely thought everyone heard of this.

Except this had nothing to do with using a VCS system for package distribution, and everything to do with indirection provided by the index.

Let's invert the question: why do you think VCSs are a good idea for package management?

I'd rather you answered the question instead of dodging it. However here are a few off the top of my head, I'm sure there are many more reasons for it and reasons against, but that is why I asked in the first place.

- There are several popular, well maintained, hosted VCS providers, such as GitHub, who have good bandwidth, and host open-source projects for free. Nice as most open-source projects are unfunded. - A VCS gives you traceability in what's changing in your package repository 'for free' - nice when you open it up to contributors. - A git-based package repository can be kept locally in relatively little space, allowing for the case where the package repo host goes down - I've had issues with being unable to install from PyPI in the past because it's down, I have not had that issue with git-based repositories, for example (not a perfect comparison). - A VCS based repository can aid in creating a system where a given state of the repo is consistent, and works together, and can be upgraded atomically. Stackage is doing something like this, providing a known working set of packages at any given release (although I'm not sure if they are backing that concept with a VCS).

I still use MacPorts and I am quite happy with it -- although I've tried to switch away a couple of times, I can't bring myself to uninstall a piece of software that's worked so reliably and faithfully for me over the years.

Maybe it's just that Homebrew turned me off right away. Back in the bad old days, when the Python 2/3 split was more serious than it is now, I had a heck of a time trying to get pandas and scipy running with Homebrew. I haven't given it a try lately so perhaps things are better now.

(I am probably also the kind of person where all the hectoring the Homebrew docs would do about installing to /usr/local eventually got on my nerves ... )

That being said, I don't use MacPorts versions of things like TeX or Ruby (I prefer MacTeX and plain old rvm).

One of the best ways to run Python on OS X (other than conda) is pyenv -- which you can easily install via homebrew

I use macports but I am not happy about having to install full blown XCode in order to install macports in order to install (insert trivial, minor package here).

Has this changed ?

I am basing this on my experience of both Snow Leopard and Mavericks ... and in those cases, I had to download and install XCode. Further, this is (I suppose) more a criticism of OSX and how it does not include basic tools ...

xcode-select --install on the CLI has been available since Mavericks (I think) and will install the CLI build tools without need to install the multi-gigabyte Xcode. I don't personally use macports, but that command should pretty much solve your issue.

I don't consider installing Xcode to be an unreasonable thing to do to - consider that 70+% of the people who buy a mac have no need for the compilers or system libraries. So it doesn't seem unreasonable to me - I mean, my debian box doesn't come with any of the devtools installed - and its a couple gigs of software to install.

> I don't consider installing Xcode to be an unreasonable thing to do to

Neither do I, but you can get away with just the command line tools. It's even on the install instructions.

10,5GB for latest Xcode which is kinda far from a trivial download size or space requirement.

xcode-select --install is more like 130mb, not 10gb.

http://osxdaily.com/2014/02/12/install-command-line-tools-ma...

I would put that number closer to 99.9%, if not 99.99%. :)

I use macports, but I had never switched away in the first place. My short list of reasons include macports keeping everything tucked neatly away under /opt by default, which means I can blow it away without having to worry about breaking anything else; it manages its own dependencies, so things don't break when system libraries change; and it does binary installs by default and checks shared libraries for breakage when things get upgraded. Generally I find it Just Works, so why change?

As a bit of history, when homebrew first landed, it existed because the author wanted to pass optimization flags to his builds [0], and found the macports build system too complex for this purpose. Homebrew's real strength is the relative transparency of the build system (it is more obvious what will happen when a build launches), which is really a reflection of this initial complaint about macports. At the time, I didn't care about optimization flags and didn't otherwise get a good vibe from the rest of the project, so stuck with macports for the reasons I listed above (less the binary installs, which didn't exist yet). Since then, I've been a bit surprised at how much Homebrew has taken off, but macports has continued to improve as well and I am still very happy with it.

[0] https://news.ycombinator.com/item?id=1198037

MacPorts is useful on multi-user systems. It installs as root, so any user of the system can access installed packages, but only admins can modify them.

I'm sure Homebrew could probably be set up this way, but the defaults are a powerful thing.

That's a mighty good reason to use Macports! I'll have to keep that in mind.

You said you could probably configure Homebrew in a similar way, but... can you now-a-days configure macports to install without root for user local packages?*

* Pardon me for the potential ignorance of this question being unreasonable or lazy.

As far as I know this has always been possible.

A random Google finds this. https://coderwall.com/p/njpsxg/building-macports-without-roo...

I still use macports, although it's mainly out of habit and I'll probably switch to brew on my next mac (I've also been trying out nix, and while I really like the idea, package availability and freshness hasn't been as good as macports or brew. Nix hasn't picked up go 1.7, for example).

My main concrete reason to prefer macports is that it has separate packages for every version of python so I can have them all installed at once for testing. I also like a lot of macports' technical decisions, like the fact that my regular user doesn't have write access to the installation directory. And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore.

> And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore

That's really awesome.

> ... has separate packages for every version of python so I can have them all installed at once for testing

Are the package versions themselves configured to be installed side by side? Or are you using multiple copies of macports[1]?

[1] https://guide.macports.org/#installing.macports.source.multi...

they work side by side, you can just call "python27" vs "python34" and the same happens for related tools (pip, pep8 etc).

The un-suffixed version ("python") refers to a default that can be switched with a single command affecting all related tools. It's great.

This is not python specific either, it also works with perl, ruby, etc

now this is a pointless feature.

time to get familiar with https://github.com/yyuu/pyenv

The fact that there is a super-specialized tool to do this demonstrates that it's not a pointless feature. It's much nicer to be able to use macports to install all the versions of python that I need instead of using brew to install pyenv and then pyenv to install python (and then pip to install python packages...)

I use MacPorts on my personal Mac because the whole system "feels" higher quality. When I install, say, FontForge, I get a usable font editor (that requires X) on my Mac. When I do so with Homebrew, I get a crippled command-line utility. It's predictable and boring, which is how I like my infrastructure.

GNU Octave packages are still well maintained on Macports (and Fink!) and we have several enthusiastic users.

I wish we could get Octave to our users without any CLI shenanigans, but it's proven very difficult to build an app bundle. We finally have one, but it's not relocatable.

http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_O...

in my experience the bundle works great, and I'm very happy that I don't have to use home-brew.

I never used it because I didn't want it to spray binaries all over a system directory. Macports is completely self-contained which I consider to be a much better design decision and less likely to cause me problems.

To turn your question around, who uses Homebrew instead of Macports?

I tried Homebrew and had lots of trouble with it. I like that MacPorts is isolated so that I don't need to worry about bad interactions with the Apple compilers and libraries.

TL;DR - habit.

Long answer: When I got myself a Mac (October 2013), I looked for a way to install software, and I was given the advice "use MacPorts or Homebrew, either is fine". So I briefly looked at both and for some reason stuck with MacPorts.

I have not had any trouble with it, so I never had a reason so reconsider.

I think the main reason I preferred MacPorts back then was that it creates its own folder hierarchy for installed software (/opt/local), while Homebrew defaulted to /usr/local. I sometimes will install stuff straight from source, which typically ends up in /usr/local, and not having anything else live there made it easier for me to keep track.

A bunch of software I need just isn't available from brew.

Ditto! I also find I tend to prefer the way macports is organized.

I switched because most of my team uses brew, but I was happy with macports, it has a sane UI and I liked the way build options could be specified (i.e. "+python +png")

The only problem I had was that some stuff requiring compilation _outside_ of macports have builds that won't work naturally (e.g. phashion gem).

This is usually solveable and rare, but annoying. OTOH I've seen similar issues with brew too (i.e. need to change openssl from system version to compiled version and recompile stuff)

I've used MacPorts since it was DarwinPorts. This isn't out of habit, I've tried Fink, Homebrew, Nix, and Pkgsrc. All of them can't hold a candle to MacPorts.

I have a super easy way to evaluate package managers, so I don't waste my time: can it install useable up to date versions of GNU Emacs (NS variant), TexLive, and Xorg Server, without hassle.

Fink is dead, so we can skip it. Emacs was never up to date on Fink anyway, so I quite using it early on.

Homebrew does not package texlive and has a pathetic error it prints out when you try 'brew install texlive' — this is why I refer to it as a toy package manager.

Nix, failed all of the packages and was crazy slow. Xorg installed, but crashed on launch.

Pkgsrc is the only one that comes close. I couldn't figure out how to install the NS variant on GNU Emacs, but everything else installed (including CLI emacs) and worked. The caveat is that all the packages had really strange names. MacPorts wins here because the packages are name as you would expect: emacs-app, texlive, xorg-server.

MacPorts could make it easier to package software. Hopefully they're working on this.

I would jump ship to Pkgsrc if it had better organizations and included macOS variants of packages.

I use it because I like it. It's organised in a way that makes sense to me and I prefer it to homebrew

For me it's just habit since I've been using MacPorts for ages. I know of Homebrew, but since MacPorts has always worked perfectly for me I've never really been motivated to look into it.