Repository navigation
Proposal: wp package is-installed subcommand #210
Description
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.
Activity
swissspidy commentedon Jan 15, 2026
This would be trivial to add, but curious, what's the use case for this?
baizmandesign commentedon Jan 15, 2026
@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 listsubcommand withgrepworks just as well for programmatic purposes. (But I am thinking architecturally in the sense of making thewp packagesubcommands commensurate with thewp pluginsubcommands, since packages are like plugins for WP CLI and should maybe be treated as such.)swissspidy commentedon Jan 15, 2026
Gotcha, thanks! Yeah for scripting it could be useful.
baizmandesign commentedon Jan 15, 2026
@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 commentedon Jan 17, 2026
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 commentedon Jan 18, 2026
Hey @swissspidy. I had some free time during a train trip and decided to work on this today. Two questions for you:
I've added the trivial amount of PHP code to implement
wp package is-installedto package-command/src/Package_Command.php and have a question about adding the Behat tests. In thepackage-install.featurefile, there are quite a few invocations of thewp package listcommand just to check whether a package was installed or uninstalled. Should those invocations simply be replaced by calls towp package is-installed? In other words, should I leave those tests as is, or should I supplement them with my tests which callwp package is-installed? Or more broadly, where should I put my tests inpackage-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 inpackage-install.feature.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 namedis_installedwhich invokesis_package_installed), but would a better approach be to turnis_package_installedinto 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 commentedon Jan 19, 2026
Ha, fascinating!
is_package_installedwas 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.featurefor this new command.baizmandesign commentedon Jan 19, 2026
@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-installedor replace all of the references towp package listwith calls towp package is-installed? The usage ofwp package listis intended to see whether a given package was installed or uninstalled, the primary purpose ofwp 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 inpackage-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.package-install.featureand perhaps make a recommendation: https://github.com/baizmandesign/package-command/commit/b119f151b13f085069031200e6c4709042fdb2cd#diff-478c73f079339f9aded6594bf0438a8384a88a381293515ce072206ea1cb7364Regarding converting
is_package_installedfrom a private method to a public method, I'll do that and might rename it tois_installedsince 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 commentedon Jan 19, 2026