"port upgrade" error message usability

[Andrew Janke]

On 1/30/22 5:12 AM, Ryan Schmidt wrote:
> On Jan 30, 2022, at 03:30, Andrew Janke wrote:
>
>>> 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.
> There is admittedly a lot to know, and several different places where things are documented (guide, wiki, manpages). This bit is documented in the first paragraph of "man port":
>
>         port is designed to operate on individual or multiple ports,
>         optionally within a single call, based on the requested action. If
>         no action is specified the port command enters shell mode, in which
>         commands are read via stdin. If no portdir or portname is specified
>         for an action, the current working directory is assumed. Batch
>         commands may be passed via a cmdfile. Port options are passed as
>         key=value pairs and take precedence over individual portname
>         options as specified in its Portfile and system-wide settings.
That's a perfectly clear explanation of it. Guess I should have spent 
more time reading the overall man page instead of going right to the 
"upgrade" subcommand.
>>> "Could not find Portfile in /Users/janke" isn't too unclear, is it?
>> IMHO, that would be a nice improvement:
> My point was that it already prints that. So I guess you're saying it would be clearer if we printed only that and not the other information?

Yep, exactly: the presence of the URL up front in the first line of the 
error message distracted me from the rest of the message and its "no 
portfile found here", and I wasn't sure if the whole thing represented 
one single error message about a single error condition, or if I was 
seeing a sequence of two errors, one about some network/URL thing, and 
then a second one that was some fallout or sequelae of the first.
> Maybe we can special-case the situation where no ports are specified and the currently directory doesn't contain a Portfile and print something more helpful, like:
>
> Error: No ports were specified and the current directory /foo/bar does not contain a Portfile
That sounds like a nice improvement to me. IMHO this error message form 
is more concise, yet contains more specifically-relevant info about what 
the error means in the context of this specific attempted operation, and 
seems more readable.
>>> 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.
> What I mean is: the user might have typed "port info" or "port uninstall" or any other port command. "outdated" is not a reasonable default (or reasonable suggested value) for each of the commands. If you're saying that different port commands should have different suggested values when no port is specified, then we would have to decide what each of those would be and see if the code that prints the error message has access to the information about which command is being run.
Ah. Yeah, this current behavior seems sensible them; switching to a 
per-command default sounds like both a lot of work, and a 
possibly-breaking user-visible behavior change.

Cheers,
Andrew