Make "port requested" an alias for "port installed requested"

[ryandesign (Ryan Carsten Schmidt)]

This aside from #55085 deserves its own ticket:

Replying to paulp:

As an aside, on the theory that setunrequested being an alias for unsetrequested sets a pretty low bar for alias urgency, perhaps we could trim port installed requested down to port requested. The ability to distinguish requested ports from incidental dependencies is in my estimation the biggest advantage of macports over homebrew, and it would be even more so with a new coat of paint. Burying it as a postfix adjective doesn't show it off to best advantage. Especially since they probably found it by typing port list requested and being instructed they should have typed a different command, while it slooooooowly generates approximately the same output.

[ryandesign (Ryan Carsten Schmidt)]

I can't decide whether I'm in favor of this or not.

The port command accepts first an action name, and then an optional list of ports upon which to perform that action. We already have the problem that we have several different actions that produce lists of ports with differences in formatting:

• list which, for each given port, shows the name, version and category that's available in the local ports tree, and defaults to the pseudo-portname all which expands to the list of all ports;
• installed which, for each given port that is installed, shows the name, version, revision, variants, and active/inactive status (and platform, archs, and install date, if you use the -v flag), and defaults to the pseudo-portname installed which expands to the list of installed ports;
• outdated which, for each given port that is outdated, shows the name, installed version and revision, and available version and revision, and defaults to the pseudo-portname outdated which expands to the list of outdated ports; and
• echo which, for each of given port, shows the name and, if given, the version, revision and variants, and defaults to no ports.

So for example you can use port outdated requested to see which of the ports you requested are outdated and what newer version is available; or port installed actinact to get installation details for those ports which are installed in multiple versions where one is active and others are inactive; or port echo leaves to get the name, version, revision and variants of each installed port that can be safely uninstalled.

On the one hand, I don't especially want to make the situation more confusing than it already is by introducing yet more port-listing actions. If we implement your suggestion, the user might wonder why we have two actions—installed and requested—that produce the same format of output. It further blurs the lines between action and pseudo-portname, making it that more difficult for users to understand the distinction. For how many other current pseudo-portnames should we introduce action aliases? Would you want port active to be an alias for port installed active? That might be confusingly similar to the existing port activate, and would at minimum reduce a convenience currently available to users: the ability to use the shortest unique abbreviation for an action. A user can currently type port ac to invoke the activate action, since no other action currently starts with "ac". If we introduce port active, then a user would have to type at minimum port activa to invoke that action.

On the other hand, I would love to devise a new list format that is capable of expressing most or all of the information we need in any context, and to then be able to combine some or all of the port-listing actions into a single "list" action, at which point for compatibility reasons existing commands like port installed and port outdated would become synonymous with port list installed and port list outdated, and one might rightly ask why some pseudo-portnames get this treatment while others don't.

[paulp (Paul Phillips)]

That I share this obsession with providing a consistent interface is what made me hesitate to open a ticket about it. But when consistency is impossible (as it is here) all considerations become probabilistic tradeoffs.

A lot of command line tools would benefit from introducing the "plumbing/porcelain" distinction. Plumbing: consistency and completeness are overriding considerations. Porcelain: whatever it is that most people are doing most of the time should be optimized for, with all other considerations secondary.