Deprecating port list

[Rainer Müller]

Jeremy Lavergne wrote:
> For "port list" specifically, I would expect a listing of package  
> names and package versions with an indication that it's out of date  
> --- much like port outdated.  I suggest we then throw in an additional  
> third column indicating the status of that specific version.  Here's  
> an example:

So you only want to see installed packages, right?

> xorg-xproto                    7.0.14_1 < 7.0.15_0       (active)
> xorg-xproto                    7.0.14_0 < 7.0.15_0       (inactive)

This is basically 'port outdated'. What would be the use of this if it
is so similar?

The duplicated ports and active/inactive status could be shown with an
additional flag for 'port outdated' if you think this is useful.

'port installed' already lists active/inactive status.

> [...]
> As for what's confusing, I feel we have too many commands available  
> that overlap on naming. 

No commands overlap on naming. You have to differentiate between
commands and pseudo-ports, which are much more powerful.

Some commands have the same name as a pseudo-port, which is probably
what you mean. But I don't think we can do anything against this.

> [...] I think it would be a good idea to either  
> consolidate or rename these functions.  Since I'm talking about  
> mimicking other port systems (for better or worse) I would expect  
> "list" to provide the basic listings we provide from other functions  
> as submethods:
> list all
> list available
> list updates
> list installed
> list extras
> list obsoletes
> list recent

list all is the same as list available, pseudo-port 'all' exists for all
commands already.

list updates sounds like our existing outdated command.

list installed is covered by the installed command and the pseudo-port
'installed'.

list obsoletes was added to trunk by me as a pseudo-port, 'obsolete'

list extras and list recent, I have no idea what is meant by those.

If this is all under the list command, I would expect the same
consistent output for all of them. But for installed I would like to see
the version which is installed, for outdated I would like to see the new
and old version.

I don't like sub-commands of commands. 'port <cmd> [--options] [args]'
is enough already.

> I would expect the searching ability to included on all these (e.g.,  
> list updates foo*).

This is already possible for existing commands which accept lists of
ports. Additionally, the use of pseudo-ports is possible, which can also
be combined using logical operators. These allows to make complicated
queries which is unique to MacPorts as far as I know. As we have such a
feature I also don't think we can simply adopt commands from other
systems, these just wouldn't fit.

Note that the command echo exists to test such expansions:
  port echo depends:expat and 'a*'
Gives you a list of all ports that depend on expat and start with the
character 'a'.

If you are concerned that new users who are already familiar with
different packagement systems have a hard time to get used to 'port', we
could create a wiki section which lists equivalent commands for other
systems.

Rainer