did you mean versioned? if you really meant vendored, could you elaborate?
I don't know about brew, but MacPorts wasn't ready when Sonoma came out. So that's a bit of a bummer for early adopter types, or folks that need to develop their own app against beta macOS and depend on ports for their setup.
It's been a while since I've looked into it, but last I knew MacPorts was much more aggressive than brew about just not sharing dependencies between packages, to avoid this kind of thing. In effect, trading disk space against fragility.
Homebrew has far better dependency management then Macports. I fine that using Macports you have to download and compile the kitchen sink every time you want a moderately complex package.
Used to use MacPorts for many, many years. But grew tired of it breaking important packages or just failing to update when doing macOS major version updates.
Also, MacPorts can many times just fail to install a package or fail to update a series of dependencies. Good luck then getting your operation important packages running ..
Anyway, switched to Brew completely a while ago when updating to Big Sur, so have no idea if Brew will also do the same thing over time, but at least their system seems more simple, which might result in less breakage.
I've been a MacPorts user since the days of Fink vs. MacPorts and tried and failed to use brew many times.
The biggest argument at the beginning for Homebrew over MacPorts was binary distribution and now MacPorts has that and can still compile custom versions if necessary.
MacPorts is always the first thing I install on a new Mac and has been for over 15 years. The several times I've seriously tried Homebrew, I get frustrated (terrible jargon, missing packages, spewing files all over my system, lax security) and go back to MP.
Last time I looked, MacPorts had a more paranoid approach to dependencies. That can be good and bad. Homebrew can be easier to use, until you run into a corner case that trips it up. MacPorts can be frustrating in how many dependencies it will insist on installing its own version even though the system-provided version might have worked.
I've gone back and forth. For a while homebrew could install a working GHC for me while I wasn't having any luck with MacPorts. Later something else caused me to switch back to MacPorts. Neither is perfect. Even MacPorts only allows dependencies at the package level, without regard to variants, or versions, if I recall correctly.
I have completely the opposite experience; brew would screw something up every other time I upgraded a package, and didn't cross OS updates very well at all. MacPorts has been rock-solid, possibly because it is more careful about making sure that ports have exactly the right deps.
Last time I looked, Homebrew wasn't even trying to deal with conflicting dependencies, or any of the other hard corner cases of package management. MacPorts at least makes a decent effort on that front.
> MacPorts is an autarky -- you get a duplicate copy of zlib, OpenSSL, Python, etc. Homebrew uses what is already there, and consequently, most stuff has zero dependencies and builds faster.
MacPort's self-sufficiency is its strength. Apple's system is managed by Apple, via Software Update. Depending on and modifying that system is foolhardy. What happens when the next point upgrade of OS X updates a library to a non-compatible version? Or what if you need ruby 1.8.7, but Leopard's ruby is at 1.8.6 (1.8.7 was a large release)? Your package system doesn't talk to Apple. Apple's update either breaks you, or your updates break OS X.
In fact, MacPorts once linked to OS X's libraries, but they found out how brittle this was, and switched to the current system.
OS X is not a Linux distribution, and it is not organized and defined by its package management system. If you want the flexibility of an open source Unix package system in OS X, you have to build one separately from Apple's Emerald City. The thing is, you can, and it works pretty well.
The problem I see most people having with the MacPorts / OS X duality actually stems from improper management of their shell's PATH. One way to manage namespace collisions is this: place MacPorts bin directories below the system PATH:
and then create symlinks in /usr/local/bin to specific MacPorts executables that you would like to have on the top of the search stack. That way, you'll use Apple's binaries by default, and then you can cherry pick the MacPorts binaries that you would like to use in place of OS X's defaults. The inverse of this works quite well too.
> Dependency resolution and updates are basic or not working yet.
I'm sure this is in the works, but my feeling is that managing dependencies and updates are the raison d'être of a package management system. Without this, you just have an installation management system; a shortcut around `make' and `ln'.
I don't know homebrew but macports wasn't that great when I tried it last. Apt-get has never failed to resolve dependencies where as macports did all the time.
"MacPorts is an autarky -- you get a duplicate copy of zlib, OpenSSL, Python, etc. Homebrew uses what is already there, and consequently, most stuff has zero dependencies and builds faster."
MacPorts made the decision to package and version their own versions of everything for a reason. Conflicts can start to arise when you start compiling against Apple's default shipped libraries for X11, Python, etc. Especially if the default shipped versions don't provide what you need. E.g. the PHP install that shipped with Snow Leopard is missing several notable extensions.
It might be safe to ignore these issues now but as the app grows they will need to be addressed. (Or of course they can ignore it and just point to MacPorts as an alternative for some subset of packages).
Note that Brew doesn't even support macOS Sierra[1]. It doesn't outright refuse to run, but there's a big warning message that stuff will break and maintainers won't care—and lots of stuff does indeed break.
Macports's support for legacy versions of OS X is unique, and dare-I-say incredible.
What's the story with MacPorts these days? When I used MacOS I preferred it over alternatives such as brew and was under the impression it was used and had contributors from Apple as well.
IIRC my issue with MacPorts was that it insisted on recompiling the world from its ecosystem as dependencies because it kept everything super-stable, whereas brew would attempt to use system ones if they were viable. It was more or less FreeBSD Ports vs. Debian apt-get as the model at that point, and MacPorts was (predictably) FreeBSD-like.
Over time I'm not sure brew is any better now, though. I have unlinked versions of gcc, python, etc., etc. under /usr/local that are there just to handle brew packages that listed them as pinned dependencies. It's nice that brew doesn't expose them to CLI unless I want it to do so, but it's not less complex.
Assuming MacPorts has a good "bottle" type concept of precompiled packages now too (haven't looked for years) it's probably about the same as brew now, just more stable. If they still compile from source every time a la BSD, that would be my main sticking point.
did you mean versioned? if you really meant vendored, could you elaborate?
I don't know about brew, but MacPorts wasn't ready when Sonoma came out. So that's a bit of a bummer for early adopter types, or folks that need to develop their own app against beta macOS and depend on ports for their setup.
reply