Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?
back
13 comments
Macports. It works and does what I need it to do. I switched to Mac from Linux, and with that background it was unnerving to see a system deliberately written to install non-root-owned files in /usr, so I ruled Homebrew out. I've always found it puzzling that people ask whether anyone "still" uses Macports, as though it is some decrepit thing. Homebrew is the one that seems strange to me.
My thoughts exactly.
I'm a daily linux user, but occasionally some job requires me to use a Mac. Every time I see some OSX tool that starts with the premise of "just go ahead and `sudo chown` a system location and then curl this script into a `sudo bash` pipe" I just think to myself, if they care so little about security to not get the easy stuff right, can I really expect them to nail the hard stuff?
Usually not. I'll have to give Macports a try. As I understand it, it's an implementation/port of the BSD ports system, so I'd expect it to have a more solid foundation.
I switched to MacPorts from Fink (RIP). It feels about the same as using pkg on a modern FreeBSD box. Pros compared to Homebrew: doesn't litter symlinks everywhere, behaves the way you expect a package manager to. Cons: Not as cool™, tends to have less frequently updated packages.
I still use macports! As for why, there are a couple of reasons.
First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new version of Openssh will break any core Mac OS components.
> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution
This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO) since you face fewer issues with breakage. OS X can update its userland tools and you generally don't care.
This is also exactly why i use MacPorts. It works. It doesn't do silly stuff. It's been consistently solid for years.
Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was to sudo -i to my primary account in a shell.
Don't get me started on "brew install docker" vs "brew cask install docker".
That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
> That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
You are probably using on old version of OS X that does not yet support TLS 1.2. Therefore system's libcurl cannot talk to https://kernel.org anymore, which got very strict recently. As a workaround, you can download the tarball manually with your browser and place it into /opt/local/var/macports/distfiles/git/.
Macports doesn't really rely on anything OS-X specific except for Xcode
And that's a big problem right there, I don't use xcode and its also a 15GB install!, so a waste to my small 128GB ssd.
Not to mention you will get nagging updates of a huge app you don't use, which takes lots of time to download and install.
Why doesn't macports make their pkg manager work just with the xcode cli tools? and for those pkgs that need xcode, tell the user they need to install xcode first.
Homebrew maintainer view: MacPorts is a good package manager built by smart people and we end up sharing e.g. patches sometimes. I used to use it before Homebrew and it was good. Nowadays it's worth using whichever one takes the approach that feels best to you.
I use pkgsrc due to portability and its clean separation between the base system and itself.
Pkgsrc is fantastic and never gave me the lib conflict headaches I had with Homebrew. It's also really easy to contribute a package or fix. Plus I use pkgsrc in the cloud, so my dev machine works like my production machine.
Can't say enough good things about pkgsrc.
MacPorts user here. It keeps ALL of its stuff in a single directory, and you just have to add it to the path. All package managers screw up from time to time, however MacPorts mistakes/inconsistencies are easily fixed, Homebrew has always been a pain in the ass for me. Also, no telemetry.
I do. I don't have anything against brew, I think it is great that it is available, but I've used Macports since before brew existed. Macports' philosophy and where it puts things just seems to jive more with how I think that type of tool should work and behave. There also might be a little bit of unjustifiable anti-ruby bias on my part at work there too. I'm glad both alternatives exist.
I use macports. No particular reason, it just works for me and I don't see any reason to switch. It also feels more BSD-like, which is a plus for me, though I didn't dig deep enough.
Yes. MacPorts. Quality and stability.
$ sudo port install texlive +full
> Error: No available formula with the name "texlive"
> ...
> You can install it with Homebrew-Cask:
> brew cask install mactex
Maybe they updated the error message. Here is what it said that last time I tried Homebrew:
$ brew info texlive
Installing TeX from source is weird and gross, requires a lot of patches,
and only builds 32-bit (and thus can't use Homebrew deps on Snow Leopard.)
We recommend using a MacTeX distribution: https://www.tug.org/mactex/We did update it, yep.
Here is one more reason I use MacPorts, because it never does crap like this:
$ brew search x11
x11vnc
Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Try again in 54 minutes 49 seconds, or create a personal access token:
https://github.com/settings/tokens
and then set it as HOMEBREW_GITHUB_API_TOKEN.This is not a Homebrew issue. This is a Github issue. The instructions regarding the API token solve the problem.
How often are you querying GitHub's API from your local machine?
I can answer that that precisely: 4. I was testing Homebrew in a virtual machine to see how it compared to MacPorts, Nix, and Pkgsrc at the time and can restore the virtual machine with Terminal still open and my complete session viewable.
Sure the "fix" is simple. But when I'm evaluating something I'm possibly going to make part of my life, I have to ask myself: how many more surprises await me?
Based on my evaluation of the available package managers, my ranking (for macOS) is:
1) MacPorts 2) Pkgsrc 3) Homebrew 4) Nix
I've encountered that error too. Sometimes, I am just seeing if stuff I want to play with are out there in brew land.
Nix package manager on my Mac [1]. Deterministic builds, plays well with POSIX/UNIX, though fewer repo's available than Brew and others.
I tried switching to nix, but homebrew's command line argument "design" has spoiled me. With homebrew I'm usually able to guess command arguments, where as with every other package manager I have to google when I want to do something I haven't done before.
For example, I want to search for a package name before installing. I'm guessing it's just "brew search pkg"... yup. Now what do I do with nix? Google says it's "nix -qa pkg", that totally makes sense, and I just love how I have to memorize some arcane letters.
This is true for virtually every linux package manager I've tried (wtf is apt-cache? I can't remember pacman commands after using it for a year). Seriously, typing anything with a minus sign is slower than typing word, so what's even the point? At this point I won't (choose to) use a package manager that doesn't get this right.
Haha, this is true, Nix's commandline is not exactly intuitive. I've been using apt, vim, and other similarly unintuitive stuff for a long time though so I just deal with it or script it, but totally understand anyone who prefers something more semantic.
Basically all of the unixy tools I need host-side (a lot of my work happens in Debian VM's or on remote Debian servers) are available as native Installer Packages (.pkg or .mpkg bundles)
This boils down to: Vagrant, Mercurial, Git, GPG Suite, Autotools, tree and wget.
And for updates you manually hunt down the new .pkg installers? Package managers are not only there to install some version of the software, but also to keep it up-to-date.
Hunting implies I don't know where to find them and have to search.
I do. Its nice an isolated and just works. I like how the options work.