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
