Does porting Homebrew make any more sense than porting something from Linux (for example)? My impression is that the Mac OS ones aren't as good.
A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.
The advantage of Homebrew is that it is modern, small, and simple. Obviously apt is better, but apt also requires that you maintain a large repository of binaries. Homebrew is slow[1], but because it builds from source it is trivial to create a new package. Homebrew packages are just Ruby files. If the project uses Autotools, all you generally need to do is enter the URL, an md5, and the dependencies, then it Just Works. If it uses waf or something it's still just a simple modification.
Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X.
This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity.
[1] really what's slow is building from source. Homebrew itself is very fast.
Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer.
In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files.
As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.
Macports builds something of a sandbox, which from the users point of view is neither small nor simple.
It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.
The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers.
I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.
If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.
The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
As a user, I find knowing that "install X from MacPorts" should always work, no matter what underlying version of Mac OS X I have, can always be up to date with the latest features, without having to update Mac OS X, and won't fail when I /do/ want to upgrade Mac OS X, the definition of "simplicity".
(Honestly: what does Homebrew make simpler than MacPorts anyway? Near as I can tell, the only reason people seem to like it is that it doesn't take as long to compile software, which argues more strongly to me that we need binary distributions that can download pre-compiled copies than that we should attempt to use the libraries to save installation time.)
1. No alternative copies of Python, Perl, Ruby, zlib, etc...
And if I need a newer version of Python, coupled with a dependency tree of third-party modules?
I don't see why this matters, other than some pedantic sense of cleanliness ("NO DUPLICATES!" ... even though they're not, in reality, duplicates).
2. Everything installs to where it is supposed to, i.e., under /usr/local/
You can configure MacPorts to do this, but the reason it's not the default was to leave /usr/local for the user's own manually installed software. I don't think this really matters either way.
After installing via Homebrew, things do not look drastically different to having compiled them by hand.
Are you perhaps thinking about the CoApp project? It's making some decent progess, check out CoApp.org for updates. Last I heard they were in the process of shallow-forking a slew of OSS projects and building them natively in Windows.
A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.