"port upgrade" error message usability

Andrew Janke floss at apjanke.net
Sun Jan 30 09:30:35 UTC 2022

On 1/30/22 4:04 AM, Ryan Schmidt wrote:
> On Jan 30, 2022, at 02:24, Andrew Janke wrote:
>> Hi, MacPorts developers,
>> Long-time Homebrew user and recent MacPorts convert here.
> Welcome! I'm interested in your impressions of MacPorts as a Homebrew user and if you have any suggestions for changes we can make to make your MacPorts experience more enjoyable.


I've been lurking on MacPorts for a while, and my general impressions 
are that MacPorts is the more "pro" product: more functionality and 
customizability, and better commitment to back-compatibility and 
long-term support. But the tools are less user-friendly and less "fun" 
(where's my beer emojis?), and portfiles are a bit harder to work with 
that Homebrew formula files (not without reason, from what I can tell). 
(I'm not just a Homebrew user; I was one of the core Homebrew 
maintainers for a few years.)

I'm the primary maintainer for Octave.app (https://octave-app.org/), a 
"native Mac app" distribution of GNU Octave 
(https://www.gnu.org/software/octave/index), and I'm getting more in to 
MacPorts recently because Octave.app is currently built on Homebrew and 
I'm considering migrating it to MacPorts, because I want to continue 
supporting macOS 10.14 with it. (10.15+ breaks some apps, so I want to 
be able to support the diehards (like me) who are sticking with 10.14).)

 >  All MacPorts commands operate on a Portfile in the current directory 
if you don't specify what ports to operate on.

This was the "implicit knowledge" I was lacking here.

 > "Could not find Portfile in /Users/janke" isn't too unclear, is it?

IMHO, that would be a nice improvement: when I'm working with the `port` 
command in a shell, I'm thinking in terms of port names and maybe local 
files; a local filesystem path is more comprehensible to me than a URL 
(even if it's a "file://..." URL; in theory I know what that means, but 
maybe not all users will, and just seeing it in URL instead of local 
file paths kinda throws me off, because that makes me think it's doing 
some networking thing that I don't understand).
> There's no reason to suspect that a user who doesn't specify a port meant to specify the pseudoport "outdated". I think it might not necessarily even be known at the time that the list of specified ports is processed which command that set of ports will be handed to.
Fair enough. That might be an assumption I'm bringing with me from the 
Homebrew world.


More information about the macports-dev mailing list