Hacker News Reader

Hacker News

Comment by bluedino | Hacker News Reader

Parent Full thread

bluedino

Does anyone use MacPorts/Fink anymore? What are the use cases for them?

View on HN

MacPorts user here. Uses case are the same, but:

- MacPorts does not track you by default with Google analytics.

- MacPorts lives by default in a self-contained directory tree.

- MacPorts tends to be more stable than Homebrew, but that’s just my personal experience.

- I didn’t like the slogans Homebrew used for years, implying MacPorts wasn’t good quality.

Also Macports works in a multi user environment without problems (as long as one either gives all users sudo access or sudo port access).

Does MacPorts have anything like Homebrew Cask? I know it's technically a plugin/addon, but it owes its existence to the Homebrew tooling and ecosystem it's on top of.

The ability to very easily install full GUI apps, or closed-source ones, is absolutely indispensable for automatically configuring Macs in many large environments, especially those (like a former one of mine) that heavily used Puppet for provisioning.

If MacPorts is lacking in that "umbrella package manager" functionality, I'd be stuck using both it and cask if I switched (and, given my positive experiences with Homebrew core and cask, I have no plans to).

The MacPorts system is flexible enough that you can use it to install any kind of software.

Honestly I don't know if that's popular, when using Homebrew and MacPorts I was always installing open source stuff...

I use MacPorts pretty heavily and prefer it over homebrew. The use-case is the same as for homebrew

I meant, what do you prefer about one vs the other

I use both homebrew and macports. The main benefit with macports for me is the ability to work with different versions at the same time. You can have applications requiring gcc4.5, gcc4.9, and gcc6 installed. The package manager handles most weird special cases and combinations.

Last I used MacPorts I thought it was more separate from MacOS, installing its own components rather than using what comes with the operating system.

I preferred the MacPorts model, but when I used them both, there seemed to be a lot less support compared to Homebrew. When builds stop working, they seemed to be fixed in Homebrew before they were fixed in MacPorts, and Homebrew also seemed to have more current versions of most packages available.

Homebrew also seems to use its own toolchain packages if they're installed. It just doesn't insist on it like MacPorts.

I switched to Brew because I got tired of recompiling from source for every update with MacPorts. As an end-user I don't see the benefit of repeating the same thing N times for N clients versus doing it once, centrally.

Every time "boost" updates, you're stuck recompiling half your ports for the next 20 minutes to use the new library. With Brew, you wait a minute for the new packages to download, and you're done.

MacPorts has been providing binary packages since 2.0, which was released in 2011. Many pre-compiled binaries are even available for old macOS versions back to 10.6. There are only a few ports where the license does not allow binary distribution.

I don't know what to tell you, I like it better. Different flavours for different folks.

I never know what to make of "people still use ______?!" comments

Is there no specific reason why you like it better? Usually you can explain why certain software is preferable to similar software. For example, I use IntelliJ over VS Code for writing Scala because I've had difficulties getting the Ensime extensions to work properly and IntelliJ usually just works. I use VS Code over PyCharm for writing Python code because it's lighter weight and offers 99% of the features that I need. We use Slack at work instead of IRC because there are a lot of non-technical people who need to communicate with the dev team and Slack offers an easy to use UI for organizations.

For myself, I like MacPorts better than Homebrew because in my experience it's subject to less breakage, less flaky interaction with tools like rvm or python, and has a better project philosophy overall. And I personally like that it's not in Ruby but I understand the opposing opinion too ;)

> I never know what to make of "people still use ______?!" comments

Usually people are assuming a network-effect that would make using not-Foo when Foo has "won" problematic. Like, imagine using MySpace as your social network today. It'd be a ghost town and nobody you knew would be on it.

In this case, I imagine people would expect that MacPorts either wouldn't have as wide a selection of packages, or wouldn't keep 100% of its packages constantly up-to-date, or some combination of the two.

Our team uses MacPorts, at this point mostly out of habit and because no-one has taken the time to try out Homebrew and see how our pipeline would work on that.

Not that we have any problems with MacPorts really.

I too am curious about qualitative differences between the two.

I like MacPorts over Homebrew because MacPorts lives in its own directory. Homebrew can hose your system binaries and that was enough for me to never use it.

Homebrew, like, for example, CPAN, runs reasonably arbitrary code at package-install time. Much of it is sandboxed, or reviewed by the maintainers, but scripts/configure programs/etc. can spray files, or remove files, anywhere they want on your system. The same is true with ill-behaved "configure; make; make install" deployment systems.

This is contrasted with something like dnf/yum, which has registries of assets that are supposed to be installed. I'm not positive, but I suspect something like that would be a way higher maintenance burden for OSX (for maintainers of the package management system and packagers themselves, many of whom have shown little to no interest in packaging for OSX, hence Homebrew's patch system).

It also lives primarily in its own directory, unless you're installing casks (which usually "do exactly what the installer would do if I downloaded and installed it myself") or packages with special cases that manage external-to-homebrew things. For packagers, the API for "use Homebrew-managed/blessed directories for e.g. --prefix configure arguments" is pretty good, but people (and bad, old build scripts) can and do still mess around outside of where they're supposed to. "Hosing your system binaries" is a pretty darn rare occurrence unless you're explicitly configuring brew to put things where it wouldn't normally.

Edit: plurals are hard.

I haven't looked into this too heavily, but my understanding is that Homebrew prefixes everything it installs. It does not touch any existing files, so uninstallation (even just to reinstall) is just deleting a directory.

MacPorts does not work the same way.

Edit: grammar.

macports user. works just fine, no reason to switch.

Reply on news.ycombinator.com