The homebrew comment (which I can't reply to for some reason) is good, but not totally fair. Homebrew has to compile everything, while this isn't a huge problem with todays machines it is still a bit of a time sink. Homebrew regularly has packages that fail to build. There are over 400 open pull requests for the project at the present time to illustrate this problem.
Homebrew != apt-get or any other linux package manager.
Moreover, homebrew doesn't provide complete package management for the entire system. Sure, it can keep track (sort of) of the packages that it installs, but it's not by any stretch a one-stop destination for anything installed on your system.
By contrast, I know that I can use exactly one tool (pacman)[1] to handle any installation, upgrade, query, removal, dependency tracking, versioning, etc, even for things like Python libraries. I don't need to futz around and try and remember how I originally installed it.
Compare that with OS X, which gave me absolute hell when I tried to do something so utterly basic as upgrade the system version of Python from 2.6 to 2.6.1, just so that I could install matplotlib (or something along those lines). In the end, I had to do some manual rm-ing and symlinking in /usr/bin/System_Python (or whatever it was) just to get everything to line up properly while at the same time not borking everything else on my system. Manual deletion of root-access files? Just to upgrade a single library? Come on, this is 2012, not 1992.... and even if it were, we still had better tools back then!
[1] Okay, technically you'll need a wrapper for the AUR like packer if you want exactly one tool; but my point still stands.
Upgrading the system Python on Mac OS X isn't easy because it's not something you should do. See http://stackoverflow.com/a/1541850 for something of an explanation about this.
My point exactly. A well-designed OS shouldn't require you to keep multiple versions installed on a machine like that. I have exactly two versions of Python on my box (a 2.7.x and a 3.x), and since I don't need to do development testing of libraries against multiple versions, that's all I should need. (And we're just talking about development tools and installation here - what about all of the other aspects of package management, which OS X completely neglects?)
In this case the problem is that libraries may not detect the alternative versions of Python if System Python is still installed. But the prepackaged versions of Python won't always install properly if you already have a Python on your system, so you're in a catch-22.
I mean take a look at the installation instructions for Matplotlib[1]. It takes about two lines to explain how to install it on Windows, and more than half the page to explain different things you have to try to get it to work on OS X. And that's not counting the copious other errors and hacks that you'll find if you try Googling the OS X installation issues.
Let's face it: if it's orders of magnitude easier to install a well-designed library on Windows than your OS, you have a problem with your OS.
> A well-designed OS shouldn't require you to keep multiple versions installed on a machine like that.
A well-designed OS should require you to install a separate version of Python if the version it provides does not suit your needs. Replacing the system version of Python means that any system components that use Python are now running in an untested configuration and may break in mysterious ways. Installing your new version elsewhere removes that concern.
> prepackaged versions of Python won't always install properly if you already have a Python on your system.
If a prepackaged version of Python for Mac OS X won't install if you already have Python on your system, then it's broken. It's that simple. Mac OS X has shipped with Python installed for years, so such a package would not install on any modern Mac OS X installation.
> I mean take a look at the installation instructions for Matplotlib.
I don't know that using Matplotlib as an example really supports your argument.
The installation notes about Mac OS X are a mess, but from my reading of that page it says as much about Matplotlib as it does about the state of Python on Mac OS X. On that page they recommend a third-party distribution of Python named EPD, but then go on to talk about how EPD has issues building Matplotlib on some versions of Mac OS X. Why would they recommend a version of Python that can't build their software? The page also spends a bunch of time talking about older versions of Matplotlib, and about packaging mechanisms that they no longer use. Neither of those things are relevant to the average person that is getting up and running with Matplotlib on Mac OS X.
As far as I can tell, this is exactly the same process as for Matplotlib on Windows. Right down to installing a version of Python from python.org. I'm not even sure that's strictly necessary. The hand-wavy mention of problems with the system version of Python on the installation page are so void of context and detail that they're impossible to evaluate.
"compile everything" is an approach to package management. BSD Ports (as well as Gentoo's Portage) use it. It does a pretty decent job at helping packaged programs build off/work with unpackaged installs. You also get some marvelous compile environment debugging adventures. ;)
Not saying it isn't an approach, I'm just saying,it's apples and oranges. When someone suggests that OSX doesn't have a linux style package management, they are technically correct.
What does "linux style" even mean? Linux is a kernel, it doesn't define how a package manager is supposed to work. Gentoo has been source compiling from ages, and is a linux distribution. If you're looking for technical correctness, your initial comment[1] is wrong in the context of Portage.
If you're looking for a reason to dislike a project like homebrew, bring up that it's nowhere close to complete system management. There's huge parts of OS X that I have to have already installed through other means just to get it up and running, and plenty more that I simply cannot install through it. That's a lot more important than wether or not you have to wait for package compilation.
[1]"Homebrew != apt-get or any other linux package manager."
Well, hang on there. I'm not here to become Mr. Homebrew Defender, but saying 'this project has 400 pull requests, that's a problem' isn't fair at all. The majority of those pull requests represent users updating formulas to new versions of things, or adding new formulas, not fixing problems that prevent things from compiling.
Like any solution, particularly a 100% opensource solution, it's not perfect, but it does do the job, the majority of the time. YMMV, but I have 24 Homebrew formulas installed and have had zero problems with any of them.
I think the point was more that in comparison to the package systems deployed for Fedora or Ubuntu or OpenSUSE (also "100% open source"), Homebrew looks, well, pathetically primitive. Seriously, look at the way launchpad or koji or OBS work sometime.
Sorry, I use and love homebrew, I'm just saying I understand the parents issue with the lack of a compiled binary package manager for OSX. Arguably I can't see anything that is preventing one from being created though. Perhaps compile-on-demand is just the way of the future.
Homebrew != apt-get or any other linux package manager.