Feature Development Discussion Recap

This week’s WP-CLI office hours had been a special “feature development and the package index” edition, as was announced in the previous post: How should we embark upon new feature development?

Here’s a link to the chat log. The attendees were: @danielbachhuber, @dave_navarro, @grapplerulrich, @miyauchi, @modernnerd, @nerrad, @schlessera.

Chat summary:

We started with a quick recap of what the different approaches were that we already presented in the previous post:

  1. No package index, but community-driven feature development
  2. Submission proposal that is coupled to precise quality and maintenance requirements
  3. Two-tiered system with both an “official” index and a “community” index

Most of the discussion that immediately followed revolved around approach C, and what the best technical implementation of such a system would be.

It is clear that this involves a lot of work on the infrastructure that supports these different tiers. Some existing package indexes/managers were mentioned as a comparison: npm/packagist in terms of being a similar CLI tool, but also rpm as a package system that allows arbitrary repositories to be added as a package source.

When I told the group that we were considering going with approach A for now, while targeting some form of C as a longer-term goal, people seemed to agree in principle. The discussion that followed then made it rather clear that we are discussing two distinct problems and trying to find a solution for both at the same time:

  1. A mechanism to install external packages that allows to differentiate between “official” and “third-party” packages.
  2. A mechanism for discovery of new packages, that allows searching and/or browsing some type of collected index.

This lead the group to reason about these two problems separately, and ultimately allowed us to formulate the following plan:

  • For installing packages, we won’t have an actual “index” in place, we accept any Composer source (git repository, zip file, path to folder, …) as a package, with the added detail that a package identifier of vendor/package will default to the corresponding GitHub repository.
  • This makes it obvious what an “official” package is: any package under the wp-cli GitHub organization.
  • This also allows all third-party packages that are hosted on GitHub to be easily installed via such a shortened package identifier, without the need to add them to any sort of index.
  • In case this is needed, we will provide a backward compatibility mapping to make sure the packages from the current package index still work as expected.
  • The current package index will be retired. It will not be deleted, though, to keep legacy versions of WP-CLI working as expected.
  • “Discovery” is then an entirely different problem and will be solved through a separate (potentially third-party) project.

We will now start work on investigating this specific approach. Expect several issues to pop up on GitHub related to this.

This also means that the actual feature development will now be handled as was described for approach A. Ideas are collected within the wp-cli/ideas repository. The ones that get the most traction get included in the roadmap to build as new official packages, which means they will be part of the wp-cli GitHub organization. We will more clearly define our policies surrounding this process and include them in the contributor’s documentation.

We are still very grateful about any feedback we can get about this important aspect of WP-CLI, so don’t hesitate to share your thoughts in the comments below!