8 ms·

Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own

by mojuba 6y ago

Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?

nicolas_t 6y ago
My experience with homebrew is that it doesn't deal well with multiple version of packages at the same time. For example, it doesn't like to keep outdated openssl in parallel, which is good from a security standpoint but can make it difficult if your job involves a lot of looking at antique codebases and help with updating them... It's why I switched back to macports after briefly testing it
- awakeasleep 6y ago
  Can you explain exactly what you are describing: “it doesnt deal well with multiple versions at the same time” Also what system/os are you comparing to?
  - cies 6y ago
    Nix(OS)?
  - capableweb 6y ago
    Don't have a ton of experience with either macports or homebrew but pretty much any package manager deals with running multiple different versions at the same time, or projects using different versions of the same dependency, without getting in your way. Biggest/most famous example I guess would be javascript/npm/npm inc registry.
    - masklinn 6y ago
      Nope, completely different “package manager”. Homebrew and Mac ports are more similar to apt or yum or Pacman, and those often do not provide for running multiples of the same software except in specific edge cases where sauf software can be argued to be different from itself e.g. python2/3, they sort of things.
  - ragnese 6y ago
    Probably comparing it to MacPorts, which does allow multiple versions of the same packages to be installed simultaneously.
  - nicolas_t 6y ago
    I'm comparing to macports. I remember a brew update that removed an old version of openssl causing all of my older ruby packages to fail. Now I would definitely not use ruby 1.9.x in production but I sometimes do have to be able to run locally antique codebases that haven't been used in a long time. I was caught off guard because a simple install of an unrelated application with homebrew destroyed a big part of my work flow. Macports never did this and kept libraries side by side cleanly. Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.
    - cutler 6y ago
      Why not just use rbenv with a $HOME/.gem directory. Much simpler as Ruby versions come with their own openssl.
      - nicolas_t 6y ago
        I was using rbenv, but try installing an ancient version of ruby through rbenv, I have never been able to get it to work without having the existing openssl library in my system (not an issue with newer versions)
        cutler 6y ago
        I think that's because rbenv only introduced bundling openssl libs at a certain point in its history so, yes, if you're going for a really old version fair point.
lawnchair_larry 6y ago
Yes
newscracker 6y ago
Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful. In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
- lucideer 6y ago
  > found it a bit cumbersome with the “no sudo” requirement This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
  - Wowfunhappy 6y ago
    The problem is that the way they do it breaks the UNIX model. /usr/local is common to all users, but Homebrew gives it the current user's permissions. This consequently creates weirdness if you actually use multiple user accounts.
    - lucideer 6y ago
      Exactly why I prefixed my comment with "this is one of the FEW features I do love". The exact technical approach Hombrew ends up taking to a lot of problems always seems not quite right whenever I've dug a little deeper.
    - kstrauser 6y ago
      Fair point, but I bet the number of Macs in the wild shared by multiple people who would want to run Homebrew are vanishingly small.
      - Wowfunhappy 6y ago
        Sure, but it's a native feature built into the Mac platform. If software is going to prevent that from working properly, then that should be communicated very clearly.
blandflakes 6y ago
I find that MacPorts is a better citizen of my laptop, but the mindshare of homebrew means that brew will have both more packages and more up to date packages. And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.
- protomyth 6y ago
  I think that's the key, MacPorts stays in its lane. I also like the variant mechanism. It makes it easy (much like OpenBSD flavors) to get what I want out of it.
- brigandish 6y ago
  I don’t use homebrew (for many of the reasons found in the comments here and more) but this is why I do visit their repo[1] for a “formula” whenever I need something macports or pkgsrc can’t supply me. [1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/PACKAGE_NAME.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...
my123 6y ago
No. MacPorts is so much better nowadays.
- dewey 6y ago
  In what way?
  - my123 6y ago
    Dependency management in Homebrew is nothing short of primitive or broken...
    - somehnguy 6y ago
      Not to mention that the recommended way of installing certain packages changes seemingly randomly sometimes. Python, PHP, OpenJDK are ones that I've specifically had issues with. It starts with finding some random blog post on Google that differs from every other blog post on Google about how to accomplish the install. Then you spend a bit looking for other references to see if the one you're following is the new way or the old way that won't work right anymore. I also very rarely update my Homebrew packages because there is no telling what will break half the time due to this. And the fact that simply installing a package force updates every other package by default! I needed a single tiny utility while on a screen share recently, I `brew install` it. 15 minutes later Brew was still figuring the world out and it ended up being faster to just find the utility on Github and download it manually to use while letting Brew do its thing in the background. Still no idea if it ever ended up installing... Don't get me wrong, I still think brew has been handy for me over the years. But I breathe a sigh of relief whenever I `apt-get` something on a Debian box and it behaves in a sane manner.
bhaak 6y ago
Homebrew is what a package manager would look like if Apple was doing it. So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong. It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own. It's more of a update manager than a true package manager.
- bacon_blood 6y ago
  I disagree. Apple would spend the time to make universal binaries work (unlike homebrew, who has stated they won't support them). Not installing universal binaries has some bad implications for Rosetta for developers. Having mixed single processor binaries in PATH can cause architectures to switch unexpectedly for subprocess chains (like when running a build tool), or even get "bad CPU type" errors in some contexts if the wrong arch is first in PATH.
  - my123 6y ago
    And MacPorts is what had/has Apple involvement actually.
    - Wowfunhappy 6y ago
      And, it does in fact support universal binaries.
  - bhaak 6y ago
    Universal binaries matter most for closed source. With Homebrew being used for Open Source software it’s by far not a priority for the generic user. The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.
    - bacon_blood 6y ago
      No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries. It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer. Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild). Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects). I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.
lucideer 6y ago
Have never used MacPorts, but based on your comment, and a few of the replies, I may give it a try. Homebrew is quite painful in many ways, particularly when managing multiple versions of a package (MySQL & PostgreSQL especially has had a lot of issues for me). On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even very small / niche / new projects will often have a Homebrew package.
- jimbokun 6y ago
  This Homebrew MacPorts discussion is giving me a MySQL Postgres vibe. The former is more popular and easier to get started with and bigger community, but the latter is higher quality and better designed.
- zymhan 6y ago
  You would probably enjoy the `port select` command in Macports to pick the version you want to launch when invoking, say, "python". Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.
SkyMarshal 6y ago
Fwiw you can use the Nix package manager (https://nixos.org/ https://nixos.org/) on OS X to accomplish those same things. Lots of discussion about that the past few years: https://google.com/?q=nix+on+mac+os+x https://google.com/?q=nix+on+mac+os+x Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there. And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew does.
- cutler 6y ago
  How is that better than a pm specifically designed for Mac?
  - Benjamin_Dobell 6y ago
    I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful. Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run. If you've ever updated readline via Homebrew, you can pretty much just watch everything burn. If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS. If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.
    - faitswulff 6y ago
      Also any random operation can take 20 minutes to complete if you haven't used brew in a while.
      - upbeat_general 6y ago
        You can disable this but I agree, I hate it. This comment actually just spurred me to find this (https://gist.github.com/jb510/99f12b1ac70f1cf8b780 https://gist.github.com/jb510/99f12b1ac70f1cf8b780) which may fix the issue of forgetting to manually update.
cutler 6y ago
Seconded, port select is great as is port variant.
shagie 6y ago
MacPorts and Homebrew have a different philosophy of software installation. MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain. This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. Homebrew, on the other hand, uses the system toolchain and tries to avoid using root. In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.
- mojuba 6y ago
  Containers cover some use cases but not all. Experimentation for one, also if you need specific compiler toolchains that you occasionally use on your sources. You don't create a Docker image each time you need a specific toolchain. MacPorts definitely shines here but it's probably not a great option for non-technical users.
- ashtonkem 6y ago
  Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly feels like a bad idea.
  - shagie 6y ago
    The flip side of that is "do you want to have two scripting and compiler toolchains installed on the machine - one that gets updates from the vendor and one that gets updates from volunteers?" The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated. I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up. That's a "my experience" story and isn't meant to be defining. I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them. For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.

by mojuba 6y ago

nicolas_t 6y ago

My experience with homebrew is that it doesn't deal well with multiple version of packages at the same time. For example, it doesn't like to keep outdated openssl in parallel, which is good from a security standpoint but can make it difficult if your job involves a lot of looking at antique codebases and help with updating them... It's why I switched back to macports after briefly testing it

awakeasleep 6y ago
Can you explain exactly what you are describing: “it doesnt deal well with multiple versions at the same time” Also what system/os are you comparing to?
- cies 6y ago
  Nix(OS)?
- capableweb 6y ago
  Don't have a ton of experience with either macports or homebrew but pretty much any package manager deals with running multiple different versions at the same time, or projects using different versions of the same dependency, without getting in your way. Biggest/most famous example I guess would be javascript/npm/npm inc registry.
  - masklinn 6y ago
    Nope, completely different “package manager”. Homebrew and Mac ports are more similar to apt or yum or Pacman, and those often do not provide for running multiples of the same software except in specific edge cases where sauf software can be argued to be different from itself e.g. python2/3, they sort of things.
- ragnese 6y ago
  Probably comparing it to MacPorts, which does allow multiple versions of the same packages to be installed simultaneously.
- nicolas_t 6y ago
  I'm comparing to macports. I remember a brew update that removed an old version of openssl causing all of my older ruby packages to fail. Now I would definitely not use ruby 1.9.x in production but I sometimes do have to be able to run locally antique codebases that haven't been used in a long time. I was caught off guard because a simple install of an unrelated application with homebrew destroyed a big part of my work flow. Macports never did this and kept libraries side by side cleanly. Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.
  - cutler 6y ago
    Why not just use rbenv with a $HOME/.gem directory. Much simpler as Ruby versions come with their own openssl.
    - nicolas_t 6y ago
      I was using rbenv, but try installing an ancient version of ruby through rbenv, I have never been able to get it to work without having the existing openssl library in my system (not an issue with newer versions)
      - cutler 6y ago
        I think that's because rbenv only introduced bundling openssl libs at a certain point in its history so, yes, if you're going for a really old version fair point.

lawnchair_larry 6y ago

Yes

newscracker 6y ago

Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful. In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

lucideer 6y ago
> found it a bit cumbersome with the “no sudo” requirement This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
- Wowfunhappy 6y ago
  The problem is that the way they do it breaks the UNIX model. /usr/local is common to all users, but Homebrew gives it the current user's permissions. This consequently creates weirdness if you actually use multiple user accounts.
  - lucideer 6y ago
    Exactly why I prefixed my comment with "this is one of the FEW features I do love". The exact technical approach Hombrew ends up taking to a lot of problems always seems not quite right whenever I've dug a little deeper.
  - kstrauser 6y ago
    Fair point, but I bet the number of Macs in the wild shared by multiple people who would want to run Homebrew are vanishingly small.
    - Wowfunhappy 6y ago
      Sure, but it's a native feature built into the Mac platform. If software is going to prevent that from working properly, then that should be communicated very clearly.

blandflakes 6y ago

I find that MacPorts is a better citizen of my laptop, but the mindshare of homebrew means that brew will have both more packages and more up to date packages. And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.

protomyth 6y ago
I think that's the key, MacPorts stays in its lane. I also like the variant mechanism. It makes it easy (much like OpenBSD flavors) to get what I want out of it.
brigandish 6y ago
I don’t use homebrew (for many of the reasons found in the comments here and more) but this is why I do visit their repo[1] for a “formula” whenever I need something macports or pkgsrc can’t supply me. [1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/PACKAGE_NAME.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...

my123 6y ago

No. MacPorts is so much better nowadays.

dewey 6y ago
In what way?
- my123 6y ago
  Dependency management in Homebrew is nothing short of primitive or broken...
  - somehnguy 6y ago
    Not to mention that the recommended way of installing certain packages changes seemingly randomly sometimes. Python, PHP, OpenJDK are ones that I've specifically had issues with. It starts with finding some random blog post on Google that differs from every other blog post on Google about how to accomplish the install. Then you spend a bit looking for other references to see if the one you're following is the new way or the old way that won't work right anymore. I also very rarely update my Homebrew packages because there is no telling what will break half the time due to this. And the fact that simply installing a package force updates every other package by default! I needed a single tiny utility while on a screen share recently, I `brew install` it. 15 minutes later Brew was still figuring the world out and it ended up being faster to just find the utility on Github and download it manually to use while letting Brew do its thing in the background. Still no idea if it ever ended up installing... Don't get me wrong, I still think brew has been handy for me over the years. But I breathe a sigh of relief whenever I `apt-get` something on a Debian box and it behaves in a sane manner.

bhaak 6y ago

Homebrew is what a package manager would look like if Apple was doing it. So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong. It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own. It's more of a update manager than a true package manager.

bacon_blood 6y ago
I disagree. Apple would spend the time to make universal binaries work (unlike homebrew, who has stated they won't support them). Not installing universal binaries has some bad implications for Rosetta for developers. Having mixed single processor binaries in PATH can cause architectures to switch unexpectedly for subprocess chains (like when running a build tool), or even get "bad CPU type" errors in some contexts if the wrong arch is first in PATH.
- my123 6y ago
  And MacPorts is what had/has Apple involvement actually.
  - Wowfunhappy 6y ago
    And, it does in fact support universal binaries.
- bhaak 6y ago
  Universal binaries matter most for closed source. With Homebrew being used for Open Source software it’s by far not a priority for the generic user. The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.
  - bacon_blood 6y ago
    No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries. It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer. Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild). Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects). I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.

lucideer 6y ago

Have never used MacPorts, but based on your comment, and a few of the replies, I may give it a try. Homebrew is quite painful in many ways, particularly when managing multiple versions of a package (MySQL & PostgreSQL especially has had a lot of issues for me). On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even very small / niche / new projects will often have a Homebrew package.

jimbokun 6y ago
This Homebrew MacPorts discussion is giving me a MySQL Postgres vibe. The former is more popular and easier to get started with and bigger community, but the latter is higher quality and better designed.
zymhan 6y ago
You would probably enjoy the `port select` command in Macports to pick the version you want to launch when invoking, say, "python". Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.

SkyMarshal 6y ago

Fwiw you can use the Nix package manager (https://nixos.org/ https://nixos.org/) on OS X to accomplish those same things. Lots of discussion about that the past few years: https://google.com/?q=nix+on+mac+os+x https://google.com/?q=nix+on+mac+os+x Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there. And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew does.

cutler 6y ago
How is that better than a pm specifically designed for Mac?
- Benjamin_Dobell 6y ago
  I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful. Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run. If you've ever updated readline via Homebrew, you can pretty much just watch everything burn. If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS. If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.
  - faitswulff 6y ago
    Also any random operation can take 20 minutes to complete if you haven't used brew in a while.
    - upbeat_general 6y ago
      You can disable this but I agree, I hate it. This comment actually just spurred me to find this (https://gist.github.com/jb510/99f12b1ac70f1cf8b780 https://gist.github.com/jb510/99f12b1ac70f1cf8b780) which may fix the issue of forgetting to manually update.

cutler 6y ago

Seconded, port select is great as is port variant.

shagie 6y ago

MacPorts and Homebrew have a different philosophy of software installation. MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain. This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. Homebrew, on the other hand, uses the system toolchain and tries to avoid using root. In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.

mojuba 6y ago
Containers cover some use cases but not all. Experimentation for one, also if you need specific compiler toolchains that you occasionally use on your sources. You don't create a Docker image each time you need a specific toolchain. MacPorts definitely shines here but it's probably not a great option for non-technical users.
ashtonkem 6y ago
Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly feels like a bad idea.
- shagie 6y ago
  The flip side of that is "do you want to have two scripting and compiler toolchains installed on the machine - one that gets updates from the vendor and one that gets updates from volunteers?" The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated. I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up. That's a "my experience" story and isn't meant to be defining. I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them. For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.