Opened 7 years ago
Last modified 7 years ago
#55089 new enhancement
Make "port requested" an alias for "port installed requested"
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.4.2 |
Keywords: | Cc: | paulp (Paul Phillips) | |
Port: |
Description
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.
Change History (2)
comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Version: | → 2.4.2 |
---|
comment:2 Changed 7 years ago by 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.
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-portnameall
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-portnameinstalled
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-portnameoutdated
which expands to the list of outdated ports; andecho
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; orport installed actinact
to get installation details for those ports which are installed in multiple versions where one is active and others are inactive; orport 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
andrequested
—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 wantport active
to be an alias forport installed active
? That might be confusingly similar to the existingport 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 typeport ac
to invoke theactivate
action, since no other action currently starts with "ac". If we introduceport active
, then a user would have to type at minimumport 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
andport outdated
would become synonymous withport list installed
andport list outdated
, and one might rightly ask why some pseudo-portnames get this treatment while others don't.