6 ms·

Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly

• 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.