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