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

[danielbachhuber]

I'm curious why none of the above solutions were ever implemented. Resources? Sponsor? Agreement?

Honestly, I think it's more a lack of momentum than anything else. It's a little bit of a solution in search of a problem — in reality, there aren't a ton of new packages created on a regular basis.

At this point, my preferred approach would be:

1. A page in the handbook that lists community packages maintained outside of the WP-CLI community.
2. Create more repos inside of this GitHub organization for common, general purpose commands.

Out of curiosity, how did you stumble upon this issue? What problem are you hoping to see addressed?

[gilzow]

Out of curiosity, how did you stumble upon this issue? What problem are you hoping to see addressed?

I've been writing several wp-cli packages that I've been installing via git url. I'm now doing a presentation on writing custom wp-cli packages and noticed the handbook mentions the package index numerous times. But when I went to investigate how to submit a package to the index (linked from the package-index page), discovered it was deprecated. That led me down a rabbit hole that ultimately brought me here. 😄

there aren't a ton of new packages created on a regular basis.

I can't speak with confidence on whether there are, or there aren't, but I'll offer this counterpoint: one possibility is people follow the same path I did above, see that the index is deprecated, but then just stop. As an example of this, you can read the discussion surrounding the deprecation (and reversal) of Gitlab's public accessibility job template.