Proposal: `wp package is-installed` subcommand

[baizmandesign]

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

I'd like to be able to determine whether a WP CLI package is installed. Yes, this is possible by using grep:

wp package list | grep package-name

But I'm thinking of creating a subcommand that peers with wp plugin is-installed. This proposed command would also exit with 0 when installed and 1 when not installed.

[swissspidy]

This would be trivial to add, but curious, what's the use case for this?

[baizmandesign]

@swissspidy Thanks for your reply. The use case is to detect the presence of packages in a programmatic manner. But isn't the use case similar to that of wp plugin is-installed?

I'm aware it's a small refinement; I've been seeking ways to contribute a little bit to WP CLI, and this seemed manageable. But perhaps there are better beginner issues to work on! As my original comment said, using the wp package list subcommand with grep works just as well for programmatic purposes. (But I am thinking architecturally in the sense of making the wp package subcommands commensurate with the wp plugin subcommands, since packages are like plugins for WP CLI and should maybe be treated as such.)

[swissspidy]

Gotcha, thanks! Yeah for scripting it could be useful.

[baizmandesign]

@swissspidy Cool! As this is a low priority (for both of us, I think), I may not begin working on this for a while.

[swissspidy]

All good. We can also give this to Copilot if desired :)

And if you have any other suggestions or ideas for improving WP-CLI, we're all ears! Always love to hear from users.

[baizmandesign]

Hey @swissspidy. I had some free time during a train trip and decided to work on this today. Two questions for you:

1. I've added the trivial amount of PHP code to implement wp package is-installed to package-command/src/Package_Command.php and have a question about adding the Behat tests. In the package-install.feature file, there are quite a few invocations of the wp package list command just to check whether a package was installed or uninstalled. Should those invocations simply be replaced by calls to wp package is-installed? In other words, should I leave those tests as is, or should I supplement them with my tests which call wp package is-installed? Or more broadly, where should I put my tests in package-install.feature? I've been putting them almost everywhere a package is installed or uninstalled, but this may be overkill, as there are about 27 instances in package-install.feature.

2. There is a private method in package-command/src/Package_Command.php named is_package_installed. It returns a boolean. I've created what in essence is a wrapper method (a public method named is_installed which invokes is_package_installed), but would a better approach be to turn is_package_installed into a public method and then to add appropriate DocBlock comments to it? I'm happy to commit a draft pull request if you'd like to see what I've done.

[swissspidy]

Ha, fascinating! is_package_installed was added as port of the original implementation in daef443 but it has been unused ever since. Let's make it public and add the appropriate comments as you suggested.

To keep the PR lightweight, let's keep the existing tests as-is and add 1-2 new tests to package-install.feature for this new command.

[baizmandesign]

@swissspidy Thanks for your reply. A couple responses:

• Regarding the Behat tests, I re-read my previous comment and realized I didn't pose my question correctly. My question should have read as follows: should I supplement the existing tests with new tests using wp package is-installed or replace all of the references to wp package list with calls to wp package is-installed? The usage of wp package list is intended to see whether a given package was installed or uninstalled, the primary purpose of wp package is-installed. (And it's being used programmatically, one of the reasons I cited to add this new command.) Replacing would greatly streamline the tests in package-install.feature, reducing the length of the file and improving readability. Many of the tests in the file go like this: attempt to install a command, check if it's installed; attempt to uninstall a command, check if it's uninstalled, etc., over and over.

  • If we only add one to two tests, there are so many places (dozens!) they could be added that I'm not sure where to put them. Here is my wip if you could take a peek at the places I began modifying package-install.feature and perhaps make a recommendation: baizmandesign@b119f15#diff-478c73f079339f9aded6594bf0438a8384a88a381293515ce072206ea1cb7364

• Regarding converting is_package_installed from a private method to a public method, I'll do that and might rename it to is_installed since no other code references it. Is renaming the method OK, or would it be more prudent to keep the existing name for historical purposes?

[swissspidy]

1. I suggested supplementing to keep the PR clean, but no strong opinion there. What you currently have is good 👍
2. We can rename. For historical purposes we have the Git history :)