Third-party command discovery

[schlessera]

As the package index has now been deprecated, we should start the discussion about whether we want a new discovery mechanism, and how that could work.

As the installation of packages has now been split off of the discovery mechanism, discovery can just as well be something entirely external to WP-CLI. It could be a full-blown package repository, but it could just as well be a specialized search engine.

[danielbachhuber]

What about GitHub repo search against the wp-cli-package label ?

[schlessera]

That will only cover commands stored on GitHub. Ideally, we'd have a discovery mechanism for finding both stand-alone commands as well as commands included with plugins, no matter where the source files are stored.

[danielbachhuber]

as well as commands included with plugins

Oh, this is an interesting idea.

[danielbachhuber]

as well as commands included with plugins

Oh, this is an interesting idea.

For plugin commands, maybe the more appropriate place would be the WordPress.org plugin repo. It'd be cool to work out a way for plugin authors to easily incorporate that detail.

[schlessera]

Yes, that might be feasible. Add a meta tag to the plugin file header, with something like:

commands: event list, event get, ...

Another approach would be to scan the plugin files for WP_CLI::add_command() calls.

[miya0001]

commands: event list, event get, ...

Oh, nice. 👍

[schlessera]

Related: https://meta.trac.wordpress.org/ticket/3126

[stefanos82]

Maybe https://wpackagist.org/ is much more appropriate suggestion than vim-awesome.

[szepeviktor]

How about Packagist?

https://packagist.org/packages/wp-cli/core-command?query=&type=wp-cli-package

[redtux]

Hi, I just found out about the fact that wp package is deprecated by running wp package browse.

Would it be possible to include this information in the docs? https://developer.wordpress.org/cli/commands/package/

Although the package index will remain in place for backward compatibility reasons, it has been deprecated and will not be updated further. Please refer to #51 to read about its potential replacement.

[gilzow]

Was a replacement ever decided on? OR if not, can we resurface the discussion?

[danielbachhuber]

Was a replacement ever decided on?

It was not.

OR if not, can we resurface the discussion?

Sure, how would you suggest moving the discussion forward?

[gilzow]

Sure, how would you suggest moving the discussion forward?

Thanks for the response, @danielbachhuber !

There are several good suggestions above, but I've been unable to find (so far) why none of them were selected as appropriate. I've read the blog post and it seems that a packagist-like solution (Satis, wpackagist, etc) would solve both the central search location, and discoverability issues.

They do not address discovering cli packages that are bundled into plugins/themes; HOWEVER, one could argue in those situations the cli functionality is worthless without the plugin/theme it is bundled into.

IMO, I don't think plugin/theme cli discoverability should be a road-block for a centralized wp-cli package repository. I'm curious why none of the above solutions were ever implemented. Resources? Sponsor? Agreement?

Edit: mispelling