"port upgrade" error message usability
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
More information about the macports-dev