port list confusion
Ryan Schmidt
ryandesign at macports.org
Thu Jun 20 02:36:12 PDT 2013
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.
More information about the macports-dev
mailing list