port list confusion

[Craig Treleaven]

At 4:36 AM -0500 6/20/13, Ryan Schmidt wrote:
>On Jun 20, 2013, at 03:01, Rainer Müller wrote:
>>  On 2013-06-20 01:31, Ryan Schmidt wrote:
>>>  The `port list` command is confusing to many users:
>>>  https://trac.macports.org/wiki/FAQ#portlist
>>>
>>>  I don't think I've ever used it myself to actually find out anything.
>>>  If I'm searching for a port, I use `port search`. And if I already
>>>  know what port I want, then I'm either trying to get information
>>>  about it (`port info` or `port deps` or `port variants`) or see if
>>>  and how it's installed (`port installed`) or if it's outdated (`port
>>>  outdated`). If I just want to see what ports match an expression, I
>>>  usually use `port echo` since `port list` is slow:
>>>  https://trac.macports.org/ticket/34561
>>>
>>>  Users who use `port list` are probably coming to MacPorts from
>>>  another platform where `list` is the correct subcommand. Taking just
>>>  one example, `npm list` is the correct way to see what npm packages
>>>  are installed.
>>
>>  I agree that 'port list' is confusing. I think we discussed it several
>>  times in the past but never reached a conclusion. One of the options was
>>  also to get rid of this command altogether.
>
>My goal is to reduce user confusion and user 
>support requests. Making `port list` behave 
>sanely should accomplish that; making it say 
>"Error: Unrecognized action 'port list'" will 
>only invite more support requests. However, 
>making it say "Error: Unrecognized action 'port 
>list'; try 'port outdated' or 'port installed'" 
>could be a step in the right direction, if there 
>is no reason why a user might want to have other 
>lists of ports, other than to see what's 
>installed or outdated. I said *I* haven't used 
>it, but I'm not sure about other users. I might 
>use it instead of `port echo` if it were as fast.
>
>>>  I'd love to combine all the "list view" commands MacPorts offers into
>>>  a single new `port list` command that shows all the information one
>>>  would want. Then `port outdated` would become an alias for `port list
>>>  outdated` and `port installed` would become an alias for `port list
>>>  installed`. I think this would reduce confusion.
>>
>>  At the moment, the output format of 'port outdated' is entirely
>>  different from 'port installed'. Assuming we want to keep the different
>>  output formats, it would not make sense for me to have that under the
>>  same 'port list' command. I expect consistent output for any list of
>>  ports I specify.
>
>Right, we currently have three different list 
>commands: list, installed, and outdated. They 
>all currently produce different output, but 
>they're all *lists* and I'm proposing that we 
>should develop a new unified output format that 
>could display all the information currently 
>displayed by those three commands.
>
>For example if you list a port that's installed 
>(whether you do so via `port list installed` or 
>`port list category:devel` or any other 
>pseudoport or directly by name) the list could 
>have extra information about the installed 
>versions, perhaps parenthetically at the end of 
>the line.
>
>If you list (regardless of what pseudoport you 
>use) a port that's installed and active, that 
>could be indicated.
>
>If you list (regardless of pseudoport) a port 
>that's installed and outdated, that could be 
>indicated.
>
>This indication could be extended to other 
>commands. For example, "port info zlib" could 
>tell you what versions, if any, of zlib you had 
>installed, which one was active, and whether it 
>was outdated.
>
>>  Remember that 'outdated' and 'installed' are
>>  pseudo-ports and merely expand to a set of ports.
>
>Currently "outdated" and "installed" are 
>confusingly both pseudoports and subcommands. My 
>proposal is that they remain pseudoports, and 
>that the subcommands be removed, or rather be 
>replaced with thin wrappers around the 
>hypothetical new and improved "list" subcommand.
>
>>  Wether I pass a
>>  pseudo-port or just some port names should not influence the output.
>
>Agreed. As far as I know, there's no way for us 
>to do otherwise, since the expansion of 
>pseudoports into a list of port names happens 
>completely separately from the evaluation of the 
>subcommand.

I agree that the port list command is of little 
use as it stands versus 'port echo', 'port 
installed' and 'port outdated'.  Further, 'port 
info' can provide almost all the same information 
as the previous four!

I'll throw in a couple of cents worth in (even 
though we've abolished the penny here in Canada!):

Option flags:  AFAIK, only 'port installed' 
reacts to the -v flag; 'port list', 'port echo', 
and 'port outdated' provide no extra info.  None 
of these subcommands respect the -q flag*.  This 
flag might be used to product output suitable for 
script processing.

'port installed' is the only one of this group 
that lists the primary category that the port 
belongs to (eg "www/apache2" or 
"devel/apr-util").  Repeating the port name with 
the category doesn't seem particularly valuable.

The -v option in 'port -v installed' adds:
"(active)" in the obvious cases
"platform=___" -- I don't see the value in this?
"archs=___" which is again useful info.

Would it make sense to implement 'port list', 
'port echo', 'port outdated' and 'port installed' 
as wrappers to 'port info'?

Craig

* There seems to be a bug with 'port -q list 
installed' as it lists ALL ports--not just those 
installed!