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!
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
