Thoughts on macOS Package Managers(saagarjha.com)
saagarjha.com
Thoughts on macOS Package Managers
https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/
91 comments
Yeah, Homebrew tends to not handle upgrades very well, especially around major versions -- I remember when their decision to change the "qt" formula from Qt 4 to Qt 5 broke pretty much everyone who had it installed.
Part of the problem is technical--IIRC they don't have any CI infrastructure to test upgrade processes--but mostly they just don't care. They'd rather have the cleanest, most elegant code today, even if it means breaking everyone who installed it yesterday. That philosophy makes sense for a lot of projects (like in SaaS, where you often deploy new versions by creating new virtual machines and installing everything from scratch), but I'm not sure it's the most productive way to run a package manager.
Part of the problem is technical--IIRC they don't have any CI infrastructure to test upgrade processes--but mostly they just don't care. They'd rather have the cleanest, most elegant code today, even if it means breaking everyone who installed it yesterday. That philosophy makes sense for a lot of projects (like in SaaS, where you often deploy new versions by creating new virtual machines and installing everything from scratch), but I'm not sure it's the most productive way to run a package manager.
> That philosophy makes sense for a lot of projects (like in SaaS, where you often deploy new versions by creating new virtual machines and installing everything from scratch),
Does that ever happen with OSX.....
Does that ever happen with OSX.....
I have been using Anaconda from Continuum Analytics for years to avoid that kind of issues after being bitten once. It is well isolated, usually installed in /usr/local/anaconda3/, and the environments are typically created in /usr/local/anaconda3/envs/
At one point you could set an option to compile Boost using the C++11 runtime, but there was nothing that enforced compiling everything that depended on Boost with similar options, usually resulting in core dumps when different parts tried to use incompatible runtimes. Attempts to start a conversation on how this could be remedied was brushed away as unnecessary.
I moved to Homebrew a few years ago because MacPorts was significantly slower in adding new versions of some of the packages I needed to use for work. I had resisted using Homebrew until that point because the architecture of MacPorts made more sense to me, and because Homebrew's permission model in /usr/local is terrible.
At this point it seems like Homebrew is the standard -- I frequently see open source projects recommending it in their installation instructions without mentioning Macports.
I also recommend Homebrew to friends and coworkers, for the reasons I already mentioned, and also because it is significantly easier to install. Go to their website and the first thing you see is an installation script. Go to the MacPorts website and you see a link to an installation page partway down. That installation page is very long and lists a number of prerequisites needed for the installation to work. Homebrew does the installation bit way better, thus making the barrier to entry far lower.
MacPorts would need to demonstrate significant advantages over Homebrew to get me to switch back.
At this point it seems like Homebrew is the standard -- I frequently see open source projects recommending it in their installation instructions without mentioning Macports.
I also recommend Homebrew to friends and coworkers, for the reasons I already mentioned, and also because it is significantly easier to install. Go to their website and the first thing you see is an installation script. Go to the MacPorts website and you see a link to an installation page partway down. That installation page is very long and lists a number of prerequisites needed for the installation to work. Homebrew does the installation bit way better, thus making the barrier to entry far lower.
MacPorts would need to demonstrate significant advantages over Homebrew to get me to switch back.
Hi, I wrote this article. I also switched from Homebrew with pretty much the same opinion as you: a lot of projects have seemed to switched to "Homebrew-only" as it's more popular (and better advertised) than MacPorts is, which I think is a shame. Regarding ease of use, though, it's not actually that bad: while the website is a bit dated, you can basically just click the "Download" button and then the link for your operating system and run the installer. And as for reasons why MacPorts is better: that's basically what my article was about ;)
As someone who switched to MacOS for work a few years ago for a new job out of a desire to not have the fudge with Linux for getting work done at work, I thought MacPorts was obsolete based on what I found online about installing packages and so on.
I thought so too at first, but it's not! It's maintained relatively actively (https://github.com/macports/macports-ports/commits/master), so I think this perspective is mostly just a result of Homebrew having better marketing/more people using it.
Now you have to fudge with MacOS package managers to get work done at work. We deploy on Linux but code on Macs. It's annoying and a lot of work to set up the dev environment on a Mac whereas on Linux I have almost everything available a package manager command away.
IME the solution for "not have to fudge with Linux for getting work done at work" has been simply to use Debian + ohmyzsh + i3wm. It has never broken for me in day-to-day use as Fedora had.
I'm pretty sad it doesn't explore Nix as it's superior in isolating and doesn't require root.
Getting started: https://medium.com/scientific-breakthrough-of-the-afternoon/...
How much effort was put into making the whole isolation: https://www.youtube.com/watch?v=73mnPBLL_20
There is even a declarative way to setup darwin process management: https://github.com/LnL7/nix-darwin
Getting started: https://medium.com/scientific-breakthrough-of-the-afternoon/...
How much effort was put into making the whole isolation: https://www.youtube.com/watch?v=73mnPBLL_20
There is even a declarative way to setup darwin process management: https://github.com/LnL7/nix-darwin
/second Nix on OSX. In addition to your reasons, it doesn't depend on the Mac community for growth and support as Homebrew and MacPorts do. Regardless how many OS X users use it, its bread and butter is NixOS and the Linux server community.
Sorry for missing Nix! I have almost zero experience with it outside of hearing that it existed, and MacPorts has been working fine for me, so I didn't go any further than that :( I'll have to try it out sometime; it's nice to know there are a couple of other options for macOS if I'm ever feeling underserved.
I used to use MacPorts, and switched to Homebrew. For exactly one reason: Homebrew uses, whenever possible, the tools already built in to macOS, where as MacPorts builds new versions of those tools in order to maintain a pristine build environment.
MacPorts' philosophy seems better in theory, but in practice it has two flaws that turned out to be very significant for me. The first is that you end up needing a huge number of ports, partly because you're duplicating the tools already on the system, but partly because in many cases you need all of those ports' dependencies as well. So upgrading anything was a huge processing sink. I wanted fifteen or twenty ports on my system, but to get those MacPorts had to install several hundred dependencies. If you ever decide you don't want one of those ports, the dependencies are still installed, and pruning the ports tree was decidedly nontrivial.
The second was dependency hell. You end up with at least two versions of everything. Which one random third party apps pick up depends on search paths. Different third party apps need different versions, and I ended up twiddling with search paths a lot. Tryin to install ROS as a standalone third-party package was a nightmare.
Homebrew has its issues, but it doesn't have these issues.
Ultimately the real problem here is that macOS package managers are bolt-on additions and not a core part of the OS. when that's the case there is not going to be any perfect solution. But for a single-user machine where the main goal is to be able to maintain a minimal set of installs, and install new ones quickly so you can get real work done, Homebrew just worked better for me.
MacPorts' philosophy seems better in theory, but in practice it has two flaws that turned out to be very significant for me. The first is that you end up needing a huge number of ports, partly because you're duplicating the tools already on the system, but partly because in many cases you need all of those ports' dependencies as well. So upgrading anything was a huge processing sink. I wanted fifteen or twenty ports on my system, but to get those MacPorts had to install several hundred dependencies. If you ever decide you don't want one of those ports, the dependencies are still installed, and pruning the ports tree was decidedly nontrivial.
The second was dependency hell. You end up with at least two versions of everything. Which one random third party apps pick up depends on search paths. Different third party apps need different versions, and I ended up twiddling with search paths a lot. Tryin to install ROS as a standalone third-party package was a nightmare.
Homebrew has its issues, but it doesn't have these issues.
Ultimately the real problem here is that macOS package managers are bolt-on additions and not a core part of the OS. when that's the case there is not going to be any perfect solution. But for a single-user machine where the main goal is to be able to maintain a minimal set of installs, and install new ones quickly so you can get real work done, Homebrew just worked better for me.
You hit the nail on the head why I had gone from MacPorts to Homebrew, and for me, the extra need for sudo was just an additional pain point.
Your last point brings up an interesting question in my mind regarding Apple's intentions for the CLI. On the one hand, they seem to care enough to add features here and there to Terminal, but then when you consider that the tools have basically zero chance of upgrades being incorporated for licensing reasons, I wonder if they plan to even have a stance on package managers, or if they are completely fine with that being purely in user land. The entire CLI experience on macOS concerns me in as much as the OOTB set of tools will continue to work, but how much more fragmented will the experience get? There's already a good chance at running across some shell code online that requires bash 4 or relies on a newer gnu version of a tool. Maybe this long tail of developers is too niche for Apple, but I imagine it's still important to many of their developers in some way.
Your last point brings up an interesting question in my mind regarding Apple's intentions for the CLI. On the one hand, they seem to care enough to add features here and there to Terminal, but then when you consider that the tools have basically zero chance of upgrades being incorporated for licensing reasons, I wonder if they plan to even have a stance on package managers, or if they are completely fine with that being purely in user land. The entire CLI experience on macOS concerns me in as much as the OOTB set of tools will continue to work, but how much more fragmented will the experience get? There's already a good chance at running across some shell code online that requires bash 4 or relies on a newer gnu version of a tool. Maybe this long tail of developers is too niche for Apple, but I imagine it's still important to many of their developers in some way.
I haven’t used MacPorts for many years now, but I remember having to untangle the messes it made on a near regular basis. Perhaps that has changed, but it certainly expedited my switch to Homebrew back then.
Good piece.
Homebrew is certainly "opinionated" and, as the article says, "abrasive".
I recently had one of those upgrade chains: new iOS needs new Xcode, new Xcode needs new OS (Mojave), new Xcode and OS need new Boost. All fine up to this point.
I'd installed Boost via Homebrew. So, fine, brew upgrade boost.
A bunch of stuff scrolls past... holy ---- it's upgrading Postgres?
Oh great. Now a whole bunch of work I have stored in a Postgres database is inaccessible. No problem, Homebrew apparently has a Postgres upgrade script now.
Except it wouldn't work, complaining "no upgrade path" from PostGIS 2.4 to 2.5.2; and Homebrew wouldn't install both at the same time. Eventually, after much experimentation, I found Postgres.app came with all the right versions, allowing me to pg_dump it all out.
But my word... while trying to figure this out I spent hours looking through the issue tracker, and the state of it. Endless snark about "we don't support old versions". Fun like this: https://github.com/Homebrew/brew/issues/5675#issuecomment-46...
It's a good tool, just don't expect any support with it, ever. I kind of feel that Homebrew's slogan should be "Homebrew locked as resolved and limited conversation to collaborators".
Homebrew is certainly "opinionated" and, as the article says, "abrasive".
I recently had one of those upgrade chains: new iOS needs new Xcode, new Xcode needs new OS (Mojave), new Xcode and OS need new Boost. All fine up to this point.
I'd installed Boost via Homebrew. So, fine, brew upgrade boost.
A bunch of stuff scrolls past... holy ---- it's upgrading Postgres?
Oh great. Now a whole bunch of work I have stored in a Postgres database is inaccessible. No problem, Homebrew apparently has a Postgres upgrade script now.
Except it wouldn't work, complaining "no upgrade path" from PostGIS 2.4 to 2.5.2; and Homebrew wouldn't install both at the same time. Eventually, after much experimentation, I found Postgres.app came with all the right versions, allowing me to pg_dump it all out.
But my word... while trying to figure this out I spent hours looking through the issue tracker, and the state of it. Endless snark about "we don't support old versions". Fun like this: https://github.com/Homebrew/brew/issues/5675#issuecomment-46...
It's a good tool, just don't expect any support with it, ever. I kind of feel that Homebrew's slogan should be "Homebrew locked as resolved and limited conversation to collaborators".
Yup. Installed something, which installed a new version of readline, which caused the old version to become garbage collected despite still being in use by other things I've installed in the past. I'm still finding things that don't work anymore due to a dylib being gone, and god help you if you're running an older OS version that's not supported by a core dependency (hello, qt).
That's why I always `brew pin <formula>` I don't need Homebrew to update (although, sometimes it still does). So, not a fully perfect solution… but the best I can have with the current state of things.
Homebrew maintainers editing other people comments is intolerable: https://news.ycombinator.com/item?id=19066630
It seems like they went through and deleted all previous versions of the comment so there isn't even any context left of this discussion. Pretty shameful.
Why does GitHub allow anyone to edit other people's comments? I could imagine an extremely limited number of scenarios where it would be useful and many where it would be harmful.
First, only anyone can edit other people’s comments; only repository admins can edit messages in the repository. Also, anecdotally, it is overwhelmingly positive to me, only harmful in extremely limited number of cases (this be one of them). Many people don’t know how to use Markdown (probably don’t bother to learn) and produce gibberish issue reports. Those would have been difficult to manage if edit were not allowed. Sure, it is possible to do without edit, but it’s the same the other way around (GitHub does keep edit history).
Github may keep edit history, but it seems like maintainers have the ability to remove previous edits of comments entirely, as is the case in the linked PR (perhaps it's limited to Enterprise?)
I don't like this. A maintainer can fake another users' comments for some very nefarious purposes.
I don't like this. A maintainer can fake another users' comments for some very nefarious purposes.
Yeah, it's an optimistic biased system, but it's a decent practical approach. The cases of maintainers being lousy seems pretty uncommon.
AFAIK the reason maintainers can completely remove revisions of comments, is because occasionally a well intentioned user pastes sensitive info into a comment and doesn't realise.
While pointing it out to the user so they can remove it themselves does work, that's an unbounded time frame (perhaps never). So just nuking it directly is "safer" in that instance.
Doesn't seem like there's any really perfect solution.
AFAIK the reason maintainers can completely remove revisions of comments, is because occasionally a well intentioned user pastes sensitive info into a comment and doesn't realise.
While pointing it out to the user so they can remove it themselves does work, that's an unbounded time frame (perhaps never). So just nuking it directly is "safer" in that instance.
Doesn't seem like there's any really perfect solution.
I know our team commonly uses it to edit canonical issues over time. It’s much easier to follow a long issue if you keep the latest information in the original text.
Also github has a lot of use outside of public repositories. If I’m not the admin of my own issue tracker, I’d switch to one where I am.
Also github has a lot of use outside of public repositories. If I’m not the admin of my own issue tracker, I’d switch to one where I am.
They also de-list older versions of popular packages like PHP 7.0. A package manager should never de-list. There are many valid reasons why someone might want to install an old version of a package.
As a user I'm not a big fan of the order of their CLI switches. For example to restart PHP-FPM:
brew services restart [email protected]
In Ubuntu the same thing is
sudo service php7.0-fpm restart
Should restarting a service require sudo? I think it should.
Should the service name be first and then the operation? I think it should as well.
Good luck convincing brew maintainers of this. It's like talking to a brick wall.
As a user I'm not a big fan of the order of their CLI switches. For example to restart PHP-FPM:
brew services restart [email protected]
In Ubuntu the same thing is
sudo service php7.0-fpm restart
Should restarting a service require sudo? I think it should.
Should the service name be first and then the operation? I think it should as well.
Good luck convincing brew maintainers of this. It's like talking to a brick wall.
The advantage to having the service name last is that you can easily list multiple services. On a default Ubuntu installation, this is now possible with systemd, another opinionated piece of software:
sudo systemctl restart php7.0-fpm
Also easier to make aliases instead of functions, if args require to be in the middle of other arguments.
Homebrew isn't great but having to manually remove and reinstall all macports every os upgrade, having to deal with messed up dependencies and debugging failed compiling errors manually, and having macports libraries conflict with other mac software and making it crash was just too much. I need at best a few tools provided by these package managers and I don't want to spend hours messing around with their configurations. I just want them to work. Brew used to have issues for me but the last couple of years it's been the least buggy experience. That's all that matters. I don't give a fuck if it uses sudo or not, where they store files, or even if I have to disable system protection. All that is simply irrelevant. I just want things to work so I can get my actual work done. That is what makes a package manager better and that's why brew these days is much better than macports.
Precisely, the goal is to do a quick 'manager install foo --bar' when called for an move on with life.
Something has always rubbed me the wrong way about homebrew. I feel like there is something about it that doesn't quite jive with Unix philosophy. It doesn't feel like a Unix tool, vague as that sounds. Assuming ownership of /usr/local as this author complains is along those lines.
It just always seems like between "just get it kinda working" and "work how I expect" it often picks the former.
It just always seems like between "just get it kinda working" and "work how I expect" it often picks the former.
It’s a Macintosh tool for Unix users. Or a Unix tool for Macintosh users, can never decide. At least that is how I’ve always explained the weirdness to myself.
Sure, but macports always seemed more unixy.
Then there's fink mentioned in the article which was popular long ago which literally was a port of Debian stuff.
At some point I was using pkgsrc from NetBSD.
So a more Unix person's type of tool exists.
Then there's fink mentioned in the article which was popular long ago which literally was a port of Debian stuff.
At some point I was using pkgsrc from NetBSD.
So a more Unix person's type of tool exists.
It says on the homebrew website that "Homebrew installs packages to their own directory and then symlinks their files into /usr/local." Is this still technically assuming ownership of /usr/local, and if I chose to install homebrew to a more reasonable directory, $HOME/homebrew, for example, what packages would break?
Reading those homebrew comment threads convinced me to switch to MacPorts. I don’t care if you’re a volunteer, that’s not how you treat users.
Homebrew maintainer here. Yes, there have been complaints of poor communication back then, and I feel those complaints were justified.
But we’ve also said we’d improve [1] and I feel that the effects already show [2] [3]. We’ve been communicating changes earlier and more clearly lately. We’ve learned a lot from user feedback, and we’re nowhere near the end.
Sad to see you go though! Happy to welcome you back anytime.
[1]: https://github.com/Homebrew/brew/issues/142#issuecomment-214...
[2]: https://twitter.com/MacHomebrew/status/1119288776830926850
[3]: https://twitter.com/MacHomebrew/status/1119502934000029696
But we’ve also said we’d improve [1] and I feel that the effects already show [2] [3]. We’ve been communicating changes earlier and more clearly lately. We’ve learned a lot from user feedback, and we’re nowhere near the end.
Sad to see you go though! Happy to welcome you back anytime.
[1]: https://github.com/Homebrew/brew/issues/142#issuecomment-214...
[2]: https://twitter.com/MacHomebrew/status/1119288776830926850
[3]: https://twitter.com/MacHomebrew/status/1119502934000029696
I'm heavily leaning that way too.
Its a bit of work to switch of course, since I use a decent amount of brew packages.
Its a bit of work to switch of course, since I use a decent amount of brew packages.
Shame there is no mention of pkgsrc, I've been using it for years.
https://pkgsrc.joyent.com/install-on-osx/
https://pkgsrc.joyent.com/install-on-osx/
Great article. Really puts into words many complaints I have against Homebrew. The non-sudo thing doesn't bother me, its the leadership. User-hostile is definitely the way to put it. I don't anticipate leaving Homebrew any time soon, but it sure would be cool if the maintainers were nicer. A favorite thing to say is that they don't owe the users anything, but I think that they forget that a lot of users are contributors too.
And they would probably contribute more if the maintainers were a little nicer.
Homebrew maintainer here. Thank you for your comment and for being sincere. I’m sorry you feel that way about user-maintainer relations. While I respect your feelings and think they are valid no matter what, would you mind linking to one or two recent examples? It’d definitely help to have a look at concrete instances where our actions felt hostile to you so we can figure out how to improve.
Everyone who interacts with the Homebrew community must be treated with respect, no exceptions, and if we maintainers suck at that then we need to be better.
Everyone who interacts with the Homebrew community must be treated with respect, no exceptions, and if we maintainers suck at that then we need to be better.
As much as homebrew has its flaws, I don't want to use MacPorts until it supports binary packages as well as building from source. It's something even FreeBSD understood; not everyone is running on 8 core machines, and I don't have the time to build GCC or LLVM on a midrange laptop CPU. No one I know uses Homebrew because it's awesome, but because they wouldn't even consider for a split second a solution that involves waiting for hour for stuff to finish building from source.
That's been true since 2012 (https://lists.macports.org/pipermail/macports-announce/2012-...)
When I moved from Linux to Mac (started iOS development and got sick of tinkering to get stuff working), I looked at both homebrew and macports.
As soon as I saw that homebrew wanted to use /usr/local instead of /opt, I avoided it. These days, /usr is part of the system, even though GNU still uses /usr/local as the default.
/opt matches where the LSB says "3rd party packages" should be installed, MacPorts is (or was) partly sponsored (and thus "blessed") by Apple and it matches the "port" packager that is used for FreeBSD.
Yes you have to do some PATH and LDPATH tricks to make sure that /opt/local/* is at the top of your paths, but other than that, MacPorts has been painless.
There are some steps to follow when a new version of Xcode (and effectively a major release of MacOS) comes out, but that's more about getting xcode to accept you've accepted Apple's license.
As soon as I saw that homebrew wanted to use /usr/local instead of /opt, I avoided it. These days, /usr is part of the system, even though GNU still uses /usr/local as the default.
/opt matches where the LSB says "3rd party packages" should be installed, MacPorts is (or was) partly sponsored (and thus "blessed") by Apple and it matches the "port" packager that is used for FreeBSD.
Yes you have to do some PATH and LDPATH tricks to make sure that /opt/local/* is at the top of your paths, but other than that, MacPorts has been painless.
There are some steps to follow when a new version of Xcode (and effectively a major release of MacOS) comes out, but that's more about getting xcode to accept you've accepted Apple's license.
Homebrew removing options is such a silly thing. Changes nothing in the end result, just makes things a more inconvenient.
There’s also https://pkgsrc.joyent.com (yes, for MacOS too).
Great article, having used both package managers I can relate. Neither one is perfect, but MacPorts tends to be FAR more reliable.
> MacPorts almost always builds packages from source
That’s a misconception. As of 2019 a properly-configured MacPorts will download almost exclusively binaries.
> MacPorts almost always builds packages from source
That’s a misconception. As of 2019 a properly-configured MacPorts will download almost exclusively binaries.
I’ve always get off about Homebrew, but never put words to it. Many of the comments here seem to mirror my feelings.
From the beginning it was as if no package managers had ever existed and they were solving packaging problems for the first time ever and ignoring not just the other Mac package managers but other package managers in general.
Then there’s the smattering of cutesy names for internal concepts: bottles and casks and tapping.
Popularity of Homebrew skyrocketed, though.
Meanwhile, MacPorts is better than ever.
From the beginning it was as if no package managers had ever existed and they were solving packaging problems for the first time ever and ignoring not just the other Mac package managers but other package managers in general.
Then there’s the smattering of cutesy names for internal concepts: bottles and casks and tapping.
Popularity of Homebrew skyrocketed, though.
Meanwhile, MacPorts is better than ever.
About the cutesy names: yes, that was probably a mistake. We’ve looked into fixing this but I feel it’s too late to change the terminology now without causing even more confusion.
Glad to hear MacPorts works well for you! Should you ever decide to come back to Homebrew, we’ll be there for you.
Glad to hear MacPorts works well for you! Should you ever decide to come back to Homebrew, we’ll be there for you.
I'm unaware of all the drama everyone else is referring to and I'd like to remain ignorant, but I really prefer the naming scheme. It's more intuitive to folks like me for whom Homebrew is our first package manager, and it really helped me understand why things are how they are in package managers in general. I appreciate a little whimsey in software.
Thanks for the feedback. That’s insightful!
In software, I’ve always preferred the more serious tone. No idea why; I love silliness and monkeying around in general.
In software, I’ve always preferred the more serious tone. No idea why; I love silliness and monkeying around in general.
Why not use Nix package manager if you're looking for an alternative to homebrew?
My personal beef with Homebrew is the amount of work they create for third-party "tap" (package collection) maintainers by constantly making breaking changes to the formula interface.
For example, Homebrew used to support compiling on both 32-bit and 64-bit systems. They provided a "is 64 bit" function that packages could use to check if they were being compiled on a 64-bit system. It worked great!
Then, Homebrew decided they no longer wanted to support 32-bit systems. Instead of doing what any reasonable project with a stable interface would do and modify the "is 64 bit" function to always return "true", they just deleted it! I found out when one of my users emailed me to let me know that my packages crashed when you tried to install them.
Changes like these mean that I spend 20% of my package-maintainer time on real work and 80% dealing with Homebrew's nonsense. Moreover, they show that Homebrew doesn't care at all about the people who maintain packages outside homebrew/core. And as someone who maintains packages outside homebrew/core, that makes me not want to continue.
For example, Homebrew used to support compiling on both 32-bit and 64-bit systems. They provided a "is 64 bit" function that packages could use to check if they were being compiled on a 64-bit system. It worked great!
Then, Homebrew decided they no longer wanted to support 32-bit systems. Instead of doing what any reasonable project with a stable interface would do and modify the "is 64 bit" function to always return "true", they just deleted it! I found out when one of my users emailed me to let me know that my packages crashed when you tried to install them.
Changes like these mean that I spend 20% of my package-maintainer time on real work and 80% dealing with Homebrew's nonsense. Moreover, they show that Homebrew doesn't care at all about the people who maintain packages outside homebrew/core. And as someone who maintains packages outside homebrew/core, that makes me not want to continue.
Can't use Homebrew for any stable operations.
I had a project that has Ruby set at version 2.5, one day Homebrew turned it into '[email protected]' and now 'ruby' was 2.6 and whenever @2.5 also upgrades, since there is no global symlink, a minor version change breaks my IntelliJ setting as the path has slightly changed.
I was using Ansible from my local Mac but dropped it thinking this might just break one day. Linux distribution vendors do far better jobs at keeping things 'as is' for years.
The only use for Homebrew for me is to install individual tools that don't have wider impact if it breaks (like ripgrep).
I had a project that has Ruby set at version 2.5, one day Homebrew turned it into '[email protected]' and now 'ruby' was 2.6 and whenever @2.5 also upgrades, since there is no global symlink, a minor version change breaks my IntelliJ setting as the path has slightly changed.
I was using Ansible from my local Mac but dropped it thinking this might just break one day. Linux distribution vendors do far better jobs at keeping things 'as is' for years.
The only use for Homebrew for me is to install individual tools that don't have wider impact if it breaks (like ripgrep).
The permissions black magic is really upsetting to me---undoubtedly, I freely and openly admit, because I don't really understand permissions, but it seems to engage in behavior that it shouldn't be able to engage in. As recounted in this old blog post[1] it does things like change the permissions on its own files even after one declares the owner to be root and sets the file as non-writeable. Now, like I said, I don't really understand how file permissions work, so I'm sure that there's a perfectly logical explanation for how that's possible---but it hardly seems consistent with the incessant claim the homebrew maintainers make that it doesn't require elevated privileges.
[1] https://paultopia.github.io/posts-output/anti-homebrew/
[1] https://paultopia.github.io/posts-output/anti-homebrew/
The contents of a homebrew-core formula definition are an implementation detail of Homebrew. Formula definitions are code. Changing that code (or its permissions) directly is completely unsupported. Users may create their own formulas in their private taps; those will never be overwritten.
If you mess with a program’s internal bits in an unsupported way (like the author of the linked blog post purportedly did), you can be happy that your changes will only get reverted on the next update and not blow up in your face.
If you mess with a program’s internal bits in an unsupported way (like the author of the linked blog post purportedly did), you can be happy that your changes will only get reverted on the next update and not blow up in your face.
To be fair, MacPorts will also ask you to have the latest Xcode, though many (dare I say most?) packages will install without it. But I do think that Homebrew's permissions are pretty broken. Apparently macOS does too, since it'll reset them (and make Homebrew unhappy) if you do a reinstall.
My understanding is that MacPorts requires Xcode to have the Apple clang compiler available. I don't think that's a particularly awful requirement.
You can get reasonably far with the Command Line Tools, which contain clang. Xcode is only necessary for some (few, in my experience) packages.
Interestingly, they now seem to have ~US$3k/month via Patreon:
https://www.patreon.com/homebrew
Wonder if they'll use it for paying maintainers or something? It's a useful amount for planning things out with. :)
https://www.patreon.com/homebrew
Wonder if they'll use it for paying maintainers or something? It's a useful amount for planning things out with. :)
In a recent podcast I listened to on The Changelog [0], I’m almost positive Mike McQuaid (homebrew creator/maintainer) talks about how they use that money when they cover Homebrew governance.
0:https://changelog.com/podcast/337
0:https://changelog.com/podcast/337
Thanks, it was interesting. :)
As a minor data point, the creator of Homebrew was Adam Vandenberg, not Mike McQuaid:
https://github.com/adamv
As a minor data point, the creator of Homebrew was Adam Vandenberg, not Mike McQuaid:
https://github.com/adamv
Incorrect, it's Mike Howell (the invert binary tree guy)
Max Howell
Oops. Sorry about that. :/
Disclaimer: I'm a MacPorts committer.
> MacPorts almost always builds packages from source
Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.
But if a port is considered not distributable because of its restrictive license or license conflicts with dependencies, binaries will not be uploaded to our official mirror so users have to build it from source. We don't provide official binaries for non-default variants or alternative prefix (the default is /opt/local) either, but organizations using MacPorts can set up private mirrors with custom ports and binaries.
port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl".
> MacPorts seems to be a bit lacking in manpower (which makes things takes slightly longer than I would have expected)
Yes, we need more contributors and committers to maintain the large collection of ports we have. Our ports are more often outdated than Homebrew because of this and our maintainer policy. We are also seeking for ways to improve our developer experience, e.g. https://github.com/macports/macports-base/pull/120 which automates updating checksums in the Portfile.
> The lack of color, as well as somewhat more cluttered and less relevant output, makes it a bit less pleasant to work with.
We talked about this in a meeting last year, but it hasn't been implemented yet. https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/...
Development of the port command is relatively inactive (severe lack of manpower). https://github.com/macports/macports-base/commits/master
> MacPorts will set up its own tools in isolation from those provided by the system
Its own versions of libraries, to be exact. See https://trac.macports.org/wiki/FAQ#syslibs for more background on this.
> builds run in “sandboxes” under the macports user, where attempts to access files outside of the build directory–which includes system tools–are intercepted and blocked
It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.
> The upside is that this approach is significantly more contained, which makes it easier to manage and more likely to continue working as macOS changes under it.
Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break. We have a migration guide here: https://trac.macports.org/wiki/Migration.
[1] https://github.com/macports/macports-infrastructure/blob/mas...
[2] https://github.com/macports/macports-base/blob/master/src/po...
> MacPorts almost always builds packages from source
Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.
But if a port is considered not distributable because of its restrictive license or license conflicts with dependencies, binaries will not be uploaded to our official mirror so users have to build it from source. We don't provide official binaries for non-default variants or alternative prefix (the default is /opt/local) either, but organizations using MacPorts can set up private mirrors with custom ports and binaries.
port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl".
> MacPorts seems to be a bit lacking in manpower (which makes things takes slightly longer than I would have expected)
Yes, we need more contributors and committers to maintain the large collection of ports we have. Our ports are more often outdated than Homebrew because of this and our maintainer policy. We are also seeking for ways to improve our developer experience, e.g. https://github.com/macports/macports-base/pull/120 which automates updating checksums in the Portfile.
> The lack of color, as well as somewhat more cluttered and less relevant output, makes it a bit less pleasant to work with.
We talked about this in a meeting last year, but it hasn't been implemented yet. https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/...
Development of the port command is relatively inactive (severe lack of manpower). https://github.com/macports/macports-base/commits/master
> MacPorts will set up its own tools in isolation from those provided by the system
Its own versions of libraries, to be exact. See https://trac.macports.org/wiki/FAQ#syslibs for more background on this.
> builds run in “sandboxes” under the macports user, where attempts to access files outside of the build directory–which includes system tools–are intercepted and blocked
It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.
> The upside is that this approach is significantly more contained, which makes it easier to manage and more likely to continue working as macOS changes under it.
Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break. We have a migration guide here: https://trac.macports.org/wiki/Migration.
[1] https://github.com/macports/macports-infrastructure/blob/mas...
[2] https://github.com/macports/macports-base/blob/master/src/po...
> port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl".
Why does this license conflict prevent from distributing the tool? The tool is under the GPL, which requires making the source code available, which it is, and it also allows linking against OpenSSL, which has its own rules, but none seem to disallow distributing binaries that come with it.
Why does this license conflict prevent from distributing the tool? The tool is under the GPL, which requires making the source code available, which it is, and it also allows linking against OpenSSL, which has its own rules, but none seem to disallow distributing binaries that come with it.
IANAL.
This article convinced me about the conflict: https://people.gnome.org/~markmc/openssl-and-the-gpl.html.
The OpenSSL license imposes certain restrictions on people wishing to distribute their program using OpenSSL, while the GPL-2.0 license says you may not impose any further restrictions when you redistribute the program. There is an exception for OS components, but MacPorts is not part of macOS.
This article convinced me about the conflict: https://people.gnome.org/~markmc/openssl-and-the-gpl.html.
The OpenSSL license imposes certain restrictions on people wishing to distribute their program using OpenSSL, while the GPL-2.0 license says you may not impose any further restrictions when you redistribute the program. There is an exception for OS components, but MacPorts is not part of macOS.
Hi, I wrote the article. As you may have noticed, I'm still learning my way around MacPorts (and writing, I guess). I haven't really gotten comfortable posting on macports-dev yet, so I hope you don't mind if I slip in a couple more questions in the development process my response ;)
> Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.
Most of my packages seem to build from source. Perhaps this is because I run on the bleeding edge (macOS Developer Seeds, macports-base/macports-ports built from ToT master)? Maybe I've triggered this by virtue of some configuration option I've set?
> Yes, we need more contributors and committers to maintain the large collection of ports we have.
I've been trying my best to help by updating whatever "port livecheck installed" gives me, provided the maintainer policy allows it :) I am curious about new ports, though: what is the policy on these? Should we aim to "mirror" packages that homebrew/core adds? Does MacPorts have any equivalent for Homebrew's Caskroom?
> Development of the port command is relatively inactive (severe lack of manpower).
I "tested the waters" with a bug for a (IMO) usability improvement, https://trac.macports.org/ticket/57950, but didn't get much of response. I have ideas for ways to improve the ergonomics of the port command (and a willingness to write code to back it), but I'm not sure what the process is to get started on this.
> Its own versions of libraries, to be exact.
Yup, this is what I meant. Poor word choice here.
> It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.
Again, poor word choice. As far as I understand, MacPorts uses the compiler toolchain from Xcode (or the CLT if you have it installed?) but will block access to random "things" that the user has installed to /usr/local.
> Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break.
I have not used MacPorts long enough to have had to do this, so I was mostly talking about MacPorts being immune to Homebrew's perennial issues with Apple changing permissions on some folder that Homebrew thought they "owned" or changing some framework/command/header that they depended on. Tangentially related, has there been any work done on making this migration between OS versions less jarring? What kinds of issues crop up?
Oh, and finally, is there any easy way to get macOS's graphical applications to find MacPorts's binaries? I've been trying a bunch of random stuff related to launchd's environment variables but they seem to be really finicky and a lot of "methods" I found online don't seem to work anymore. And official suggestions?
> Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.
Most of my packages seem to build from source. Perhaps this is because I run on the bleeding edge (macOS Developer Seeds, macports-base/macports-ports built from ToT master)? Maybe I've triggered this by virtue of some configuration option I've set?
> Yes, we need more contributors and committers to maintain the large collection of ports we have.
I've been trying my best to help by updating whatever "port livecheck installed" gives me, provided the maintainer policy allows it :) I am curious about new ports, though: what is the policy on these? Should we aim to "mirror" packages that homebrew/core adds? Does MacPorts have any equivalent for Homebrew's Caskroom?
> Development of the port command is relatively inactive (severe lack of manpower).
I "tested the waters" with a bug for a (IMO) usability improvement, https://trac.macports.org/ticket/57950, but didn't get much of response. I have ideas for ways to improve the ergonomics of the port command (and a willingness to write code to back it), but I'm not sure what the process is to get started on this.
> Its own versions of libraries, to be exact.
Yup, this is what I meant. Poor word choice here.
> It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.
Again, poor word choice. As far as I understand, MacPorts uses the compiler toolchain from Xcode (or the CLT if you have it installed?) but will block access to random "things" that the user has installed to /usr/local.
> Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break.
I have not used MacPorts long enough to have had to do this, so I was mostly talking about MacPorts being immune to Homebrew's perennial issues with Apple changing permissions on some folder that Homebrew thought they "owned" or changing some framework/command/header that they depended on. Tangentially related, has there been any work done on making this migration between OS versions less jarring? What kinds of issues crop up?
Oh, and finally, is there any easy way to get macOS's graphical applications to find MacPorts's binaries? I've been trying a bunch of random stuff related to launchd's environment variables but they seem to be really finicky and a lot of "methods" I found online don't seem to work anymore. And official suggestions?
> Maybe I've triggered this by virtue of some configuration option I've set?
Maybe the port is not distributable, I've listed several situations in the parent comment where ports would be built from source, if none applies in your case you can ask on the macports-dev mailing list posting the output of port -v install [port].
> provided the maintainer policy allows it
We welcome any pull requests, the maintainer policy is for committers merging PRs.
> I am curious about new ports, though: what is the policy on these? Should we aim to "mirror" packages that homebrew/core adds?
Generally, any open-source software can be added to MacPorts. Feel free to add software Homebrew provides, but don't limit yourself to that :)
> Does MacPorts have any equivalent for Homebrew's Caskroom?
No, but you can use a custom ports tree (https://guide.macports.org/#development.local-repositories). In some cases (e.g. OpenJDK) we would repack binaries, but we prefer building ports from source (on our Buildbot or during install if binaries are not distributable).
We could discuss this on macports-dev. Creating a repository on GitHub and writing (un)install instructions is all we need to get started.
> https://trac.macports.org/ticket/57950
Our Trac tickets are somewhat neglected, please post on macports-dev if no one responds. If the change is simple, you can also make a pull request which is easier to review and merge.
> has there been any work done on making this migration between OS versions less jarring?
Yes, but the PR is stalled for now (lack of manpower again). https://github.com/macports/macports-base/pull/56
I haven't experienced these issues myself because I would always reinstall MacPorts after a major macOS upgrade.
Maybe the port is not distributable, I've listed several situations in the parent comment where ports would be built from source, if none applies in your case you can ask on the macports-dev mailing list posting the output of port -v install [port].
> provided the maintainer policy allows it
We welcome any pull requests, the maintainer policy is for committers merging PRs.
> I am curious about new ports, though: what is the policy on these? Should we aim to "mirror" packages that homebrew/core adds?
Generally, any open-source software can be added to MacPorts. Feel free to add software Homebrew provides, but don't limit yourself to that :)
> Does MacPorts have any equivalent for Homebrew's Caskroom?
No, but you can use a custom ports tree (https://guide.macports.org/#development.local-repositories). In some cases (e.g. OpenJDK) we would repack binaries, but we prefer building ports from source (on our Buildbot or during install if binaries are not distributable).
We could discuss this on macports-dev. Creating a repository on GitHub and writing (un)install instructions is all we need to get started.
> https://trac.macports.org/ticket/57950
Our Trac tickets are somewhat neglected, please post on macports-dev if no one responds. If the change is simple, you can also make a pull request which is easier to review and merge.
> has there been any work done on making this migration between OS versions less jarring?
Yes, but the PR is stalled for now (lack of manpower again). https://github.com/macports/macports-base/pull/56
I haven't experienced these issues myself because I would always reinstall MacPorts after a major macOS upgrade.
npm installation is broken with brew. had to use the standalone installer coz none of the workarounds would add npm to the path correctly(brew has some problems with access permissions and can't be sudo forced to get those permissions)
kinda irritating
kinda irritating
Are you talking about the `node` package? That’d be strange because the package definitely creates a `npm` symlink in /usr/local/bin and that has always worked for me.
Care to elaborate a bit on the permission problems?
Care to elaborate a bit on the permission problems?
https://gist.github.com/rcugut/c7abd2a425bb65da3c61d8341cd4b... it's this "known" unfixable issue and i was too lazy to do the workaround properly(i want to work with node not spend another hour figuring out the intricacies of node's interaction with brew) and googling online led me to the simple solution of just installing the package from node directly.
big fail imo
big fail imo
The sudo-less operation of homebrew bothers me greatly too :/
But I just want to say thank you very much to The Homebrew team, if you're reading this, I really appreciate your efforts.
But I just want to say thank you very much to The Homebrew team, if you're reading this, I really appreciate your efforts.
I previously had many issues with MacPorts but I am certainly going to be revisiting it.
Where to begin. it's a Homebrew hit-piece extolling how the inaccessible and system-modifying MacPorts is "superior." Bologna! I don't trust MacPorts, it's old, confusing, has terrible UX and promotes system-entropy increase (read: weird gotchas and eventual reinstalls). Leave my goddamn system alone. I don't trust giving a community package sudo.. ever. I don't pipe bash into shell, so no sudo for you either, mister package manager.
No sale.
No sale.
> I don't trust MacPorts, it's old, confusing, has terrible UX and promotes system-entropy increase
MacPorts is old, but I think that's a good thing: it's robust and well designed–at least compared to Homebrew, I feel. It's lacking a bit of color and a few emojis, but usability isn't that bad (in fact, I would say it has fewer surprises, because commands usually do exactly what they expect you to and nothing else behind your back).
> I don't pipe bash into shell, so no sudo for you either, mister package manager.
Sorry, what? I don't know that the first part means, and the second is standard across almost every system package manager.
MacPorts is old, but I think that's a good thing: it's robust and well designed–at least compared to Homebrew, I feel. It's lacking a bit of color and a few emojis, but usability isn't that bad (in fact, I would say it has fewer surprises, because commands usually do exactly what they expect you to and nothing else behind your back).
> I don't pipe bash into shell, so no sudo for you either, mister package manager.
Sorry, what? I don't know that the first part means, and the second is standard across almost every system package manager.
sudo is required if you are installing packages that are going to be usable for multiple users. And given that MacOS has SIP, which locks down /bin /usr etc, sudo is a reasonable idea for a package manager.
MacOS was not made for multi-users on one machine.
Sure it was. That's why it allows multiple user accounts with a number of privilege levels, and gives each user a separate directory tree for storing documents etc.
OS9 and below were not.
However, OS X and macOS definitely were.
However, OS X and macOS definitely were.
I don't blame MacOS- there was no expectation that an OS for 16-bit CPUs with no VM, no protected memory, and only cooperative multitasking would have proper multiuser support. With that kind of hardware, what's the point? Good thing macOS inherited all that stuff from BSD and Mach.
I mean, it's Unix, so you could say it was designed for multiple users on one machine?
Weird, here it reads
$ wc -l /etc/passwd
$ wc -l /etc/passwd
108 /etc/passwdAm I crazy to refuse to use a package manager on macOS? I thing that you should just follow the instructions and understand how to install a project. As an example, I use a lot FFmpeg, just doing brew install ffmpeg does not make sense for me; there are so many options... you need to understand what they are and the implications...
No, I also do not use one.
OS X already provides enough UNIX to my taste, no need to look beyond it.
Everything else I need is part of the SDK.
OS X already provides enough UNIX to my taste, no need to look beyond it.
Everything else I need is part of the SDK.
It's totally fine as my code was python3 compatible, but I was surprised that they'd apply a breaking change like this silently. Unlike OSes which might do this kind of thing with a major version update, I was surprised, and it took me a little while to diagnose what happened.
When I checked the GitHub discussions about the change, I found two things: 1) The maintainers claimed they had given a soft deprecation message a few months prior -- but brew doesn't stop for user input, it just posts walls and walls of messages, so I had naturally tuned it out. 2) The maintainers were getting ballistic mad at people who didn't think this was handled well.
Of course, open source is open source, and maintainers owe us nothing, but I was surprised that such a critical piece of infrastructure was being managed by people who imho handled a potentially non-trivial transition like this and who clearly didn't have the diplomatic tact to handle their userbase.