Homebrew is NOT the primary package manager on Mac and I wish people would stop perpetuating that falsehood. Apple includes pkgutil/pkgbuild in the OS and that official package management strategy plays much better with corporate IT control of managed machines.
In my experience, Homebrew always eventually results in pain and complex debugging and it's almost impossible to audit software it installs to prevent the installation of prohibited or dangerous software.
It's really not that hard to build a .pkg file and developers that want to properly support the Mac platform should go down that path before offering Homebrew support.
App Store is the primary package manager on Mac (which can be used from CLI). Homebrew is the defacto standard complimentary package manager on Mac. Whether you like the fact it is the defacto standard or not is irrelevant.
Well, I'll admit this is the first I'm learning of this tool. That said…
The top hit on Google for "os x pkgbuild" is a link into Apple's documentation that 404s. (Further Googling turns up some blog posts, and man pages, so that's good.) Does this support dependencies? How do I get updates to users? How does a user receive updates?
Wow...I'm not sure why Apple has taken down it's documentation for the command-line tools. It's been so long since I looked at anything beyond the man pages, I didn't realize the web docs weren't up. If I had to hazard a guess, I'd bet they're trying to move developers towards an XCode-centric approach. But there are plenty of other tools that can generate that format too. And it's the only format that's natively understood by the OS, so I still stand by my assertion that Homebrew is not the official package manager for Mac.
It might not be the official package manager, but what was claimed is that it is the primary package manager. I’d wager that Homebrew is more used than... I don’t even remember what you mentioned as the other one as I’ve never heard of it before and have never used it.
The best part is that some people think 'brew' is a solid package manager and then show up in Linux and try to make 'linuxbrew' happen (no really, it is a thing).
I just wish everyone would take a day and read an intro to nix/nixpkgs and the world would really be a better place. There are so many "popular" hyped tools these days that can barely do a fraction of what is going on in the Nix ecosystem, but it doesn't seem to get the hype that brew, buildkit, linuxkit, etc all seem to get.
Say what you will about Homebrew, but we need more package managers that can easily install without root. Not everyone has the time and energy to compile from source, and often it's a circular problem - I need to compile and install Python 3.7, which needs openssl, which needs to be compiled from source, which has even more dependencies... ad nauseam.
Why do we need more of them when we already have a number that are capable of deploying into a home directory? As someone who has worked on software that has needed packaging, and someone who tries to help out with packaging for a distribution, I can't imagine why we need more for the sake of having more.
Per my original comment, nix can do this, for example and already has an enormous number of packages packed, pre-built/cached, ready to go.
As my comment implies, nix and nixpkgs can do what `linuxkit` does (in terms of image building, at least) but better and in a more powerful manner.
I can create nix derivations that look like a linuxkit yaml, but instead of having a bunch of opaque sha256 hashes to some container in them, it has symbolic references to packages that are defined in my nixpkgs repository. This nixpkgs repository includes package definitions for basically everything in a distribution. From it, out of the box, you can issue single commands to build: VM images, container images, images ready to deploy on GCE/AWS/Azure, all from a single set of package definitions.
This means I can issue a single command that will output a VM image (or a container) that includes the exact revisions of all of my software, down to the kernel options and compiler flags. It makes it trivial to take in patches for critical components and rebuild a base image. No cloning extra repos. No build, container build, push, grab sha256, copy sha256 into a yaml file. Just specify the patch, hit rebuild, done.
You can do this for VM images, specifying the total system configuration - how you want etcd/kubelet/etc running, for example. One command and you have a bootable Azure VHD. You can then use the same tree, or maybe a different branch, and declaratively(!), very minimally [1] build the most optimal container images that you then have deployed to Kubernetes or wherever.
And you can be sure that you can build this exact configuration in 1 year, 2 years, 3 years, etc, due to how Nix works.
I hope I've done a somewhat okay job of explaining this. I'm trying to take some time and write a "container oriented look at why Nix is cool" guide soon too.
In my experience, Homebrew always eventually results in pain and complex debugging and it's almost impossible to audit software it installs to prevent the installation of prohibited or dangerous software.
It's really not that hard to build a .pkg file and developers that want to properly support the Mac platform should go down that path before offering Homebrew support.