A command for browsing, installing, updating and deleting community commands

[danielbachhuber]

Originally: #424

Continuation of https://github.com/danielbachhuber/wp-cli-package-command

Let's get this shipped.

[danielbachhuber]

Grab bag of pieces to finish up:

• wp package browse should list all available packages in http://wp-cli.org/package-index/
• wp package install should install a package using Composer.
• ::is_community_package should check whether a given Composer package has wp-cli listed as a dependency.
• Functional tests for all subcommands.
• Should be able to use wp package without a WP install.

[danielbachhuber]

Another for the hit list:

• wp package update and wp package update-all should update one and many packages, respectively.

@scribu Should installing a package also handle any dependencies for the package? How far down the rabbit hole do we want to go?

[scribu]

Should installing a package also handle any dependencies for the package?

Yes; it should do everything that composer require does, basically.

[scribu]

Maybe it would be best for the first iteration to have a hybrid approach: offload everything we can to the composer binary and implement the rest in PHP, using the composer lib.

[scribu]

As a general guideline, it's more important to re-use the same logic that Composer uses; it doesn't matter at this point if the output it generates doesn't match the style of normal WP-CLI commands.

[scribu]

Or we could do a polyfill for array_column().

[scribu]

Hey, there's even a Composer package: https://github.com/ramsey/array_column :)

[danielbachhuber]

wp package install is functional.

I decided against calling exec() on the Composer binary for a couple of reasons:

• Seems ugly and sad.
• We've already deviated some from strict Composer ethos (e.g. we have wp package uninstall, our output formatting is different than Composer, etc.), and I'd rather follow WP-CLI-isms instead of melding in Composer-isms.

With that being said, being able to leverage the Composer PHP library in the background is quite nice. We get a fair amount for free, like support for multiple installation mechanisms.

Another task still needing to be done:

• Install a package's dependencies, and remove them on uninstall.

@scribu Can you give this a bang and checklist any other tasks you'd like to see completed before MVP? The last open piece in my head is how we handle Composer's --dev flag vs. being able to install specific versions of a community package. Oh, and whether we're calling these "community packages", "community commands", or something else.

[scribu]

Nitpick: it's not a Packagist repo; it's a Satis repo. The official®™ name is "package index".

[scribu]

@scribu Can you give this a bang and checklist any other tasks you'd like to see completed before MVP?

Yeah, I'll take it for a spin soon.

[scribu]

The WP-CLI package index URL should be under the wp-cli key, if you use the following command to add it:

composer config repositories.wp-cli composer http://wp-cli.org/package-index/

[scribu]

The following series of steps fails:

$ wp package install pixline/wp-cli-theme-test-command
Success: Package installed.
$ wp package list
Error: There aren't any WP-CLI community commands installed.

We need some Behat tests for this.

[scribu]

Oh, and whether we're calling these "community packages", "community commands", or something else.

I think "community packages" is better because a package can contain anything, not just commands.

For example, you might write a package that only calls WP_CLI::set_logger() and defines no commands.

[scribu]

Erm... yeah, this needs a lot more work than I thought. But, I think we're getting there.

[danielbachhuber]

:) Getting somewhere at least. Hopefully it's where we want to go. I'll have some time on Sunday to work on this.

[scribu]

If I'm on a development branch of WP-CLI and I try to install a package manually, I get this:

  Problem 1
    - Installation request for wp-cli/server-command dev-master -> satisfiable by wp-cli/server-command[dev-master].
    - Conclusion: remove wp-cli/wp-cli dev-package-manager-v2
    - wp-cli/server-command dev-master requires wp-cli/wp-cli >=0.11 -> satisfiable by wp-cli/wp-cli[dev-master, v0.11.0, v0.11.1].
    - Can only install one of: wp-cli/wp-cli[dev-package-manager-v2, dev-master].
    - Can only install one of: wp-cli/wp-cli[v0.11.0, dev-package-manager-v2].
    - Can only install one of: wp-cli/wp-cli[v0.11.1, dev-package-manager-v2].
    - Installation request for wp-cli/wp-cli dev-package-manager-v2 -> satisfiable by wp-cli/wp-cli[dev-package-manager-v2].

That's because the server-command package has "wp-cli/wp-cli": ">=0.11".

Not sure what to do about it right now; I just know that it's a problem.

[scribu]

The easiest solution would be to remove the wp-cli/wp-cli requirement from community packages.

In wp package list, we could run each package through $package_index->hasPackage( $package ); to distinguish them from ordinary packages.

$package->getRepository() doesn't help, because RepositoryInterface doesn't have a method for getting the URL it comes from.

[scribu]

Missing a trailing comma here.

[scribu]

Related: #665

[scribu]

When WP-CLI is installed as a phar archive, we can't use the bundled autoload.php file, so we'd have to use a separate composer.json

So, I think we should resolve #698, so that one could do require: /extra-packages/vendor/autoload.php.