wp-cli / package-command

Lists, installs, and removes WP-CLI packages.

wp-cli/package-command

Lists, installs, and removes WP-CLI packages.

Quick links: Using | Installing | Contributing | Support

Using

This package implements the following commands:

wp package

Lists, installs, and removes WP-CLI packages.

wp package

WP-CLI packages are community-maintained projects built on WP-CLI. They can contain WP-CLI commands, but they can also just extend WP-CLI in some way.

Learn how to create your own command from the Commands Cookbook

EXAMPLES

# List installed packages.
$ wp package list
+-----------------------+------------------+----------+-----------+----------------+
| name                  | authors          | version  | update    | update_version |
+-----------------------+------------------+----------+-----------+----------------+
| wp-cli/server-command | Daniel Bachhuber | dev-main | available | 2.x-dev        |
+-----------------------+------------------+----------+-----------+----------------+

# Install the latest development version of the package.
$ wp package install wp-cli/server-command
Installing package wp-cli/server-command (dev-main)
Updating /home/person/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.005 seconds
Analyzed 732 packages to resolve dependencies
Analyzed 1034 rules to resolve dependencies
 - Installing package
Writing lock file
Generating autoload files
---
Success: Package installed.

# Uninstall package.
$ wp package uninstall wp-cli/server-command
Removing require statement for package 'wp-cli/server-command' from /home/person/.wp-cli/packages/composer.json
Removing repository details from /home/person/.wp-cli/packages/composer.json
Removing package directories and regenerating autoloader...
Success: Uninstalled package.

wp package browse

Browses WP-CLI packages available for installation.

wp package browse [--fields=<fields>] [--format=<format>]

Lists packages available for installation from the Package Index. 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 wp-cli/ideas#51 to read about its potential replacement.

OPTIONS

[--fields=<fields>]
	Limit the output to specific fields. Defaults to all fields.

[--format=<format>]
	Render output in a particular format.
	---
	default: table
	options:
	  - table
	  - csv
	  - ids
	  - json
	  - yaml
	---

AVAILABLE FIELDS

These fields will be displayed by default for each package:

• name
• description
• authors
• version

There are no optionally available fields.

EXAMPLES

$ wp package browse --format=yaml
---
10up/mu-migration:
  name: 10up/mu-migration
  description: A set of WP-CLI commands to support the migration of single WordPress instances to multisite
  authors: Nícholas André
  version: dev-main, dev-develop
aaemnnosttv/wp-cli-dotenv-command:
  name: aaemnnosttv/wp-cli-dotenv-command
  description: Dotenv commands for WP-CLI
  authors: Evan Mattson
  version: v0.1, v0.1-beta.1, v0.2, dev-main, dev-dev, dev-develop, dev-tests/behat
aaemnnosttv/wp-cli-http-command:
  name: aaemnnosttv/wp-cli-http-command
  description: WP-CLI command for using the WordPress HTTP API
  authors: Evan Mattson
  version: dev-main

wp package install

Installs a WP-CLI package.

wp package install <name|git|path|zip> [--insecure]

Packages are required to be a valid Composer package, and can be specified as:

• Package name from WP-CLI's package index.
• Git URL accessible by the current shell user.
• Path to a directory on the local machine.
• Local or remote .zip file.

Packages are installed to ~/.wp-cli/packages/ by default. Use the WP_CLI_PACKAGES_DIR environment variable to provide a custom path.

When installing a local directory, WP-CLI simply registers a reference to the directory. If you move or delete the directory, WP-CLI's reference breaks.

When installing a .zip file, WP-CLI extracts the package to ~/.wp-cli/packages/local/<package-name>.

If Github token authorization is required, a GitHub Personal Access Token (https://github.com/settings/tokens) can be used. The following command will add a GitHub Personal Access Token to Composer's global configuration: composer config -g github-oauth.github.com <GITHUB_TOKEN> Once this has been added, the value used for <GITHUB_TOKEN> will be used for future authorization requests.

OPTIONS

<name|git|path|zip>
	Name, git URL, directory path, or .zip file for the package to install.
	Names can optionally include a version constraint
	(e.g. wp-cli/server-command:@stable).

[--insecure]
	Retry downloads without certificate validation if TLS handshake fails. Note: This makes the request vulnerable to a MITM attack.

EXAMPLES

# Install a package hosted at a git URL.
$ wp package install runcommand/hook

# Install the latest stable version.
$ wp package install wp-cli/server-command:@stable

# Install a package hosted at a GitLab.com URL.
$ wp package install https://gitlab.com/foo/wp-cli-bar-command.git

# Install a package in a .zip file.
$ wp package install google-sitemap-generator-cli.zip

wp package list

Lists installed WP-CLI packages.

wp package list [--fields=<fields>] [--format=<format>]

OPTIONS

[--fields=<fields>]
	Limit the output to specific fields. Defaults to all fields.

[--format=<format>]
	Render output in a particular format.
	---
	default: table
	options:
	  - table
	  - csv
	  - ids
	  - json
	  - yaml
	---

AVAILABLE FIELDS

These fields will be displayed by default for each package:

• name
• authors
• version
• update
• update_version

These fields are optionally available:

• description

EXAMPLES

# List installed packages.
$ wp package list
+-----------------------+------------------+----------+-----------+----------------+
| name                  | authors          | version  | update    | update_version |
+-----------------------+------------------+----------+-----------+----------------+
| wp-cli/server-command | Daniel Bachhuber | dev-main | available | 2.x-dev        |
+-----------------------+------------------+----------+-----------+----------------+

wp package update

Updates all installed WP-CLI packages to their latest version.

wp package update 

EXAMPLES

$ wp package update
Using Composer to update packages...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.074 seconds
Analyzed 1062 packages to resolve dependencies
Analyzed 22383 rules to resolve dependencies
Writing lock file
Generating autoload files
---
Success: Packages updated.

wp package uninstall

Uninstalls a WP-CLI package.

wp package uninstall <name> [--insecure]

OPTIONS

<name>
	Name of the package to uninstall.

[--insecure]
	Retry downloads without certificate validation if TLS handshake fails. Note: This makes the request vulnerable to a MITM attack.

EXAMPLES

# Uninstall package.
$ wp package uninstall wp-cli/server-command
Removing require statement for package 'wp-cli/server-command' from /home/person/.wp-cli/packages/composer.json
Removing repository details from /home/person/.wp-cli/packages/composer.json
Removing package directories and regenerating autoloader...
Success: Uninstalled package.

Installing

This package is included with WP-CLI itself, no additional installation necessary.

To install the latest version of this package over what's included in WP-CLI, run:

wp package install [email protected]:wp-cli/package-command.git

Contributing

We appreciate you taking the initiative to contribute to this project.

Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

For a more thorough introduction, check out WP-CLI's guide to contributing. This package follows those policy and guidelines.

Reporting a bug

Think you’ve found a bug? We’d love for you to help us get it fixed.

Before you create a new issue, you should search existing issues to see if there’s an existing resolution to it, or if it’s already been fixed in a newer version.

Once you’ve done a bit of searching and discovered there isn’t an open or fixed issue for your bug, please create a new issue. Include as much detail as you can, and clear steps to reproduce if possible. For more guidance, review our bug report documentation.

Creating a pull request

Want to contribute a new feature? Please first open a new issue to discuss whether the feature is a good fit for the project.

Once you've decided to commit the time to seeing your pull request through, please follow our guidelines for creating a pull request to make sure it's a pleasant experience. See "Setting up" for details specific to working on this package locally.

Support

GitHub issues aren't for general support questions, but there are other venues you can try: https://wp-cli.org/#support

This README.md is generated dynamically from the project's codebase using wp scaffold package-readme (doc). To suggest changes, please submit a pull request against the corresponding part of the codebase.

package-command's Issues

Uninstallation leaves VCS repository behind

When you install a package from a VCS repository, WP-CLI first adds that repository to its composer.json file, and then requires the package.

On unistallation, the require statement is correctly removed, but the VCS repository setting that was added is left behind. This can then break subsequent package manager operations, depending on where that setting is pointing to and what has happened to the related repository.

As an example, having a VCS repository setting in composer.json that points to a GitHub repository that has since been deleted makes all package manager operations fail because Composer fatals.

Tests fail when building Phar

From #6

Fatal error: Uncaught InvalidArgumentException: The "vendor/wp-cli/wp-cli/vendor/wp-cli/config-command/templates" directory does not exist. in vendor/symfony/finder/Finder.php:656
    Stack trace:
    #0 vendor/wp-cli/wp-cli/utils/make-phar.php(139): Symfony\Component\Finder\Finder->in('/home/travis/bu...')
    #1 {main}
      thrown in vendor/symfony/finder/Finder.php on line 656

Notice the path is incorrect: vendor/wp-cli/wp-cli/vendor/wp-cli/

Peer Certificate Mismatch on Package Install

All package install attempts on RHEL6 (PHP 5.3.3) and RHEL7 (PHP 5.4.16) systems fail with:

Error: The "https://wp-cli.org/package-index/packages.json" file could not be downloaded: Peer certificate CN=`ssl391970.cloudflaressl.com' did not match expected CN=`wp-cli.org'
failed to open stream: HTTP request failed!

The command succeeds on macOS 10.13.3 (PHP 7.1.7). A direct command line curl of https://wp-cli.org/package-index/packages.json from the RHEL servers is successful, so the CN verification seems to be something specific being done in PHP curl. Any thoughts at a workaround?

installing package on Intranet

Hi, very much appreciate for this.

I can't figure out how to install my package.
It says "https://wp-cli.org/package-index/packages.json file could not be downloaded"
when "wp package install " cause its on a intranet.

Is there any way to install my package manualy? or avoid to connect out side of network.

I tried to install from zip but doesn't work.
path to "composer" is globaly added and "wp" command too.

thanks.

Commands Cookbook link goes to a 404

The link to the Command Cookbook on the page at https://developer.wordpress.org/cli/commands/package/ goes to http://wp-cli.org/docs/commands-cookbook/ which gives a 404.

The updated URL should be https://make.wordpress.org/cli/handbook/commands-cookbook/

Allow install from a Git repository specific branch

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

I would like to install a command from a remote repository non-master branch.
Eg: I forked a built-in wp-cli command and my changes are not merged (yet) but available in my own repository (but on a custom branch).

Describe the solution you'd like

Using my package's flavor on a remote machine could be as simple as:
wp package install https://github.com/my/export-command.git:@my-forked-branch
(But alternative syntax could be even better)

Move command over to new v2 structure

The following changes need to be made to move the command over to the v2 structure:

• Make sure the correct framework is required:

  composer require wp-cli/wp-cli:^2
  

• Require the testing framework as a dev dependency:

  composer require --dev wp-cli/wp-cli-tests:^0
  

• Use the .travis.yml file from wp-cli/wp-cli:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
  

• Add the default script configuration to Composer file:

    "scripts": {
        "lint": "run-linter-tests",
        "phpcs": "run-phpcs-tests",
        "phpunit": "run-php-unit-tests",
        "behat": "run-behat-tests",
        "prepare-tests": "install-package-tests",
        "test": [
            "@lint",
            "@phpcs",
            "@phpunit",
            "@behat"
        ]
    },
  

• Remove scaffolded binary files:

  git rm bin/install-package-tests.sh
  git rm bin/test.sh
  

• Remove scaffolded Behat setup:

  git rm features/bootstrap/*
  git rm features/extra/*
  git rm features/steps/*
  

• Remove scaffolded Behat tags util script:

  git rm utils/behat-tags.php
  

• Add command packages that are needed for Behat tests as --dev dependencies.
  The following commands are already available, anything else needs to be explicitly required:
  • cli *
  • config *
  • core *
  • eval
  • eval-file
  • help
• Update all dependencies:

  composer update
  

• Optional - Add PHPCS rule set to enable CS & compatibility sniffing:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
  

• Run and adapt tests to make sure they all pass:

  composer test
  

Add command to get information about single package

As suggested in wp-cli/i18n-command#53 (comment), there could be a new wp package version command to get the version of a single command.

Perhaps this could also just be wp package get <package> [--fields=<fields>] so one can easily get any specific field for a package.

Ideally we abstract the code in such a way that a single package is able to get its own version using that way.

PHP Fatal Error on listing packages

Hi,

Running this command:
./wp-cli.phar package list

Im having this PHP Fatal Error:

PHP Fatal error:  Uncaught RuntimeException: Failed to execute git clone --mirror '[email protected]:wp-cli/admin-command.git' '/home/user/.cache/composer/vcs/git-github.com-wp-cli-admin-command.git/'

 in phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Util/Git.php:310
Stack trace:
#0 phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Util/Git.php(199): Composer\Util\Git->throwException('Failed to execu...', '[email protected]:...')
#1 phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Util/Git.php(226): Composer\Util\Git->runCommand(Object(Closure), '[email protected]:...', NULL, true)
#2 phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Repository/Vcs/GitDriver.php(60): Composer\Util\Git->syncMirror('[email protected]:...', '/home/user...')
#3 phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Repository/Vcs/GitHubDriver.php(508): Composer\Repository\Vcs\GitDri in phar:///var/www/bin/wp-cli.phar/vendor/composer/composer/src/Composer/Util/Git.php on line 310

The thing is I dont have permission to execute this line git clone --mirror '[email protected]:wp-cli/admin-command.git' '/home/user/.cache/composer/vcs/git-github.com-wp-cli-admin-command.git/', so despite my error I think wp-cli should control the RuntimeException to not give a PHP Fatal Error.

Allow composer ^2.0

Hi,

Would it be possible to support composer ^2.0 instead of ^2.0.0? Thus allowing versions >=2.0 and <3.0.

Thanks

Documentation about where packages get installed to

When you installed a package using, for example, wp package install [email protected]:wp-cli/scaffold-package-command.git, the command gets installed into ~/.wp-cli/packages/vendor/wp-cli/scaffold-package-command but I had to do some hunting around to find out that this was the case.

This is particularly useful information for people who want to contribute to a community package.

Phar v1.4.0 produces errors in Composer autoloader

The Phar download of version 1.4.0 produces errors in the Composer autoloader. It tries to include the PHPCS Standards Installer package, which is not part of the Phar however (as it is a dev-dependency).

As that installer is a Composer plugin, it becomes active as soon as Composer becomes active, so just stripping it from the Phar as a dev-dependency would mean we'll have to rebuild the Composer autoloader for the Phar with --no-dev first.

Legacy package index prevents installation of current release of a package

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

I'm trying to install a package, pressbooks/pb-cli, which is listed in the now-deprecated WP-CLI Package Index.

The current release of the package is 2.1.0 (corresponding to pressbooks/pb-cli@cc81de0). However, installing via the package command always installs the last release listed in the WP-CLI Package Index, which was 2.0.1 (corresponding to pressbooks/pb-cli@9fb35e6). If I try to specify the 2.1.0 version, I get the following error:

Your requirements could not be resolved to an installable set of packages.
Problem 1
    - Root composer.json requires pressbooks/pb-cli 2.1.0, it is satisfiable by pressbooks/pb-cli[2.1.0] from composer repo (https://repo.packagist.org) but pressbooks/pb-cli[dev-master, dev-dev, 1.0.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.7.0, 1.8.0, 1.8.1, 1.8.2, 2.0.0, 2.0.1] from composer repo (https://wp-cli.org/package-index) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.

Describe how other contributors can replicate this bug

• Run: wp package install pressbooks/pb-cli
• Inspect lock file in ~/.wp-cli/packages/composer.lock
• Observe that the installed version is as follows:

          "name": "pressbooks/pb-cli",
            "version": "dev-master",
            "source": {
                "type": "git",
                "url": "https://github.com/pressbooks/pb-cli.git",
                "reference": "9fb35e6129bbf51b53408671edce9bee5b75964d"
            }
          }

• Run: wp package uninstall pressbooks/pb-cli
• Run: wp package install pressbooks/pb-cli:2.1.0
• Observe the error that ensues:

Your requirements could not be resolved to an installable set of packages.
Problem 1
    - Root composer.json requires pressbooks/pb-cli 2.1.0, it is satisfiable by pressbooks/pb-cli[2.1.0] from composer repo (https://repo.packagist.org) but pressbooks/pb-cli[dev-master, dev-dev, 1.0.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.7.0, 1.8.0, 1.8.1, 1.8.2, 2.0.0, 2.0.1] from composer repo (https://wp-cli.org/package-index) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.

Describe what you would expect as the correct outcome

As the package index is no longer being updated, I'd expect Packagist to be the higher priority repository.

Let us know what environment you are running this on

OS: Darwin 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
Shell: /bin/zsh
PHP binary: /usr/local/Cellar/[email protected]/7.4.20/bin/php
PHP version: 7.4.20
php.ini used: /usr/local/etc/php/7.4/php.ini
MySQL binary: /usr/local/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.5.9-MariaDB, for osx10.16 (x86_64) using readline 5.1
SQL modes: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /Users/ned/Sites/cli-test
WP-CLI packages dir: /Users/ned/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.5.0

Provide a possible solution

There could be a flag to explicitly bypass the WP-CLI Package Index.

Provide additional context

This also happens in GitHub Actions.

Lock framework to stable version again before release

The framework dependency was changed to request dev-master to receive a fix that produced test failures in this repository (see #116).

This needs to be reverted to a stable version before the next release.

check_git_package_name hardcode reference to GitHub

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

wp package install https://gitlab.com/my/package.git

=>

Warning: Couldn't download composer.json file from 'https://raw.githubusercontent.com/my/package/master/composer.json' (HTTP code 404).
Presuming package name is 'my/package'.

Repository is at gitlab.com, "real" name must not be checked at raw.githubusercontent.com

This breaks further package name resolution if the repository name is not the same than the package name.

`wp help scaffold package` test failure

The test Update a package with an update available currently fails:

01. $ wp help scaffold package
    
    Error: This does not seem to be a WordPress install.
    Pass --path=`path/to/wordpress` or run `wp core download`.
    cwd: /tmp/wp-cli-test-run-591f3264d39651.94458000/
    exit status: 1
    In step `When I run `wp help scaffold package`'.           # vendor/wp-cli/wp-cli/features/steps/when.php:29
    From scenario `Update a package with an update available'. # vendor/wp-cli/package-command/features/package-update.feature:28
    Of feature `Update WP-CLI packages'.                       # vendor/wp-cli/package-command/features/package-update.feature

I think we should add all of the help commands as protected commands. I don't think they would ever need to actually do stuff.

Handle more git providers in set_composer_auth_env_var()

As of #47, we support GitHub. There are a few other providers we could support too:

• bitbucket-oauth
• gitlab-oauth
• gitlab-token
• http-basic

"Fatal error: Uncaught Error: Class 'Mustangostang\Spyc' not found in phar" test failure

From #11

(::) failed steps (::)
01. $ /tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar package install path-command
    
    Fatal error: Uncaught Error: Class 'Mustangostang\Spyc' not found in phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Configurator.php:303
    Stack trace:
    #0 phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Configurator.php(219): WP_CLI\Configurator::load_yml('/tmp/wp-cli-pac...')
    #1 phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(680): WP_CLI\Configurator->merge_yml('/tmp/wp-cli-pac...', NULL)
    #2 phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/ConfigureRunner.php(23): WP_CLI\Runner->init_config()
    #3 phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/bootstrap.php(75): WP_CLI\Bootstrap\ConfigureRunner->process(Object(WP_CLI\Bootstrap in phar:///tmp/wp-cli-test-run-59255fc6881718.50526158/wp-cli-build-59255fc68875b4.95509327.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Configurator.php on line 303

Add option to package list to access locally only and not check for updates.

See #59 (comment)

An option to not bother checking for updates to packages would be useful to avoid GITHUB_TOKEN and Composer auth issues like the above and is sometimes all one wants to know and would also be much much faster.

Might also consider combining with or having some local caching of update info.

Packages installed from git where the git user has capital letters don't show up in `package list`

I've created an example command here: https://github.com/CapitalWPCLI/examplecommand

To reproduce:

1. wp package install [email protected]:CapitalWPCLI/examplecommand.git
2. wp package list, see that it is not in the list
3. go and look at the composer.json file in ~/wp-cli/packages folder. See that the package's key is the github user : repository
4. because of the code that lists the packages matches the package id (all lowercase) with what's in the composer json, it will not be matched.

Environment

$ uname -a
Darwin GaborrMBP 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

$ which -a php
/usr/local/bin/php
/usr/bin/php

$ php -v
PHP 7.1.10 (cli) (built: Oct  6 2017 01:08:53) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans

no suhosin

Which version of WordPress
none, not specific

$ which -a wp
stat $(which wp)
/usr/local/bin/wp
16777220 56521130 -rwxr-xr-x 1 javorszky staff 0 4292472 "Oct 15 13:03:17 2017" "Sep 10 17:58:46 2017" "Sep 27 16:50:55 2017" "Sep 10 17:58:44 2017" 4194304 8384 0 /usr/local/bin/wp

Hope this is enough information.

Prefer packagist.org over Github

The package manager seems to immediately download via GitHub when you use a shorthand package identifier.

It should check https://packagist.org/ first and default to that if it finds the corresponding package, as packagist is much faster for installations and updates.

Unnecessary variable declaration

https://github.com/wp-cli/package-command/blob/master/src/Package_Command.php#L728

PR incoming

Notice when browsing the package index

As we have now deprecated the package index, and have not yet decided about what discovery mechanism we might implement, we should display a notice when running wp package browse about this.

I'm thinking about something like this:

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 https://github.com/wp-cli/ideas/issues/51 to read about its potential replacement.

Automatically rerun failed scenarios

The following changes need to be made:

1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:

- composer behat || composer behat-rerun

2. In the composer-json file, the requirement on wp-cli/wp-cli-tests needs to be adapted to require at least v2.0.7:

"wp-cli/wp-cli-tests": "^2.0.7"

3. In the composer-json file, the "scripts" section needs to be extended. Immediately after the line "behat": "run-behat-tests",, the following line needs to be inserted:

"behat-rerun": "rerun-behat-tests",

---

Here's an example of how this should look like:

Improve 'wp package' command description

Improve command description in:
https://github.com/wp-cli/package-command/blob/master/src/Package_Command.php
Command: wp package
Current description: Manage WP-CLI packages.

Proposed description:
Runs WP-CLI package manager commands.

Cannot install package from private repo

In previous versions of WP-CLI it was possible to install packages from private repos so long as the command line user had access to that repo.

As of at least WP-CLI 1.5.0 this is no longer possible and attempting to install a package from a private repo resulted in an error:

wp package install [email protected]:{private/repo}.git
Error: Couldn't download composer.json file from 'https://raw.githubusercontent.com/{private/repo}/master/composer.json' (HTTP code 404).

This appears to be a result of the HTTPS for the raw.githubusercontent.com not being authenticated from the command line.

curl https://raw.githubusercontent.com/{private/repo}/master/composer.json
404: Not Found

This may be a result of #31

Installation of any package fails with no error

Hi,
I'm trying for a few hours now to install a package, but I fail miserably. I'm trying to set up a global package path (WP_CLI_PACKAGES_DIR=/usr/share/wp-cli/packages) where users have pre-installed packages. For that, I install as root.

root@48181fde35ba:/usr/share/wp-cli/packages# wp package install --allow-root --debug wp-cli/admin-command
Debug (bootstrap): No readable global config found (0.071s)
Debug (bootstrap): No project config found (0.071s)
Debug (bootstrap): argv: /usr/local/bin/wp package install --allow-root --debug wp-cli/admin-command (0.071s)
Debug (bootstrap): ABSPATH defined: / (0.071s)
Debug (bootstrap): Running command: package install (0.071s)
Installing package wp-cli/admin-command (dev-master)
Updating /usr/share/wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Reverted composer.json.

Cool. Reverted composer.json. Okay, but why? No answer. Because the composer.json is reverted, I don't have it to test a installation with composer itself. So I want and CTRL+C'ed out of wp package install so I get the composer.json. That bringe me to:

root@48181fde35ba:/usr/share/wp-cli/packages# composer install
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 0 removals
Generating autoload files

That seemd to have worked pretty well. So why is wp package failing? I have no idea.

Is there a way to debug this? Can I see any error messages? Looking at https://github.com/wp-cli/package-command/blob/master/src/Package_Command.php#L337 there should be at least SOME messages, but they are not helpful.

I have tested this as non-root user just to be sure. No luck.

Error not shown on "Reverted composer.json"

Thanks for the amazing plugin guys!

Is there any way that the error can be shown ?
I saw my composer.json "File was Reverted", but really had no idea why.

Had to go search in

#64
#27
wp-cli/wp-cli#4289

In order to understand that my package failed to install because of a "memory limit."

Finally, came across the tests to understand the reasons why that could occur.

https://github.com/wp-cli/package-command/blob/5182bca582708776ca78e746f4021d473ec94e6e/features/package.feature

Let me know guys!

Add option to be non-interactive.

See #60 (review)

Composer supports being run non-interactively so it could be useful to have an option to set this.

In particular it would avoid getting prompted for one's ssh password as can happen depending on one's authorization settings, which is problematic for scripts.

SSL certificate problem: certificate has expired

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

wp package install fails due to expired certificate

Describe how other contributors can replicate this bug

This command:

wp package install wp-cli/find-command

returns this error:

Error: curl error 60 while downloading https://wp-cli.org/package-index/packages.json: SSL certificate problem: certificate has expired

Describe what you would expect as the correct outcome

I would expect that the package wp-cli/find-command would be installed.

Environment

OS:	Darwin 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 arm64
Shell:	/usr/local/bin/fish
PHP binary:	/Applications/MAMP/bin/php/php8.0.8/bin/php
PHP version:	8.0.8
php.ini used:	/Applications/MAMP/bin/php/php8.0.8/conf/php.ini
MySQL binary:	
MySQL version:	
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/rah/Sites
WP-CLI packages dir:	/Users/rah/.wp-cli/packages/
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.5.0

Command to determine if a package is already installed

When installing a package, I only want to run the installer if the package isn't already installed.

Example usage:

if ! $(wp package is-installed foo/bar); then
	wp package install foo/bar
fi

Determine if git from prefix also and add `.git` suffix if not there.

Currently a package is determined to be a git only if the .git extension is present.

If given a standard github url like https://github.com/wp-cli-test/repository-name (or its ssh equivalent) without the .git suffix then it should also determine it to be a git package and append the .git suffix automatically.

SSL certificate cannot be retrieved from Phar

The SSL certificate override we use to avoid the Composer certificates does not work from within the Phar. We need to extract the certificate first and point to the generated temporary file instead.

This is the root cause for wp-cli/wp-cli#4791

Broke composer commands when used with phpcodesniffer-composer-installer

Hi,

I am not sure which one is causing the issue, but I just noticed that using at the same time this package with dealerdirect/phpcodesniffer-composer-installer broke composer post install commands.

Steps to reproduce

1. Create a minimal composer.json file:

{
  "require": {
    "php": ">=7.0.0"
  },
	"require-dev": {
		"wp-cli/package-command": "*@stable",
		"dealerdirect/phpcodesniffer-composer-installer": "*"
	},
  "scripts": {
    "post-install-message": [
      "echo 'Oooops'"
    ],
    "post-install-cmd": [
      "composer run post-install-message"
    ],
    "post-update-cmd": [
      "composer run post-install-message"
    ]
  }
}

2. Run composer install

Result

> post-update-cmd: composer run post-install-message
Executing command (CWD): composer run post-install-message

Fatal error: Uncaught Error: Class 'Symfony\Component\Process\ProcessBuilder' not found in /src/test/vendor/dealerdirect/phpcodesniffer-composer-installer/src/Plugin.php:118
Stack trace:
#0 /src/test/vendor/dealerdirect/phpcodesniffer-composer-installer/src/Plugin.php(103): Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\Plugin->init()
#1 /src/test/vendor/composer/composer/src/Composer/Plugin/PluginManager.php(236): Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\Plugin->activate(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#2 /src/test/vendor/composer/composer/src/Composer/Plugin/PluginManager.php(205): Composer\Plugin\PluginManager->addPlugin(Object(Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\Plugin))
#3 /src/test/vendor/composer/composer/src/Composer/Plugin/PluginManager.php(261): Composer\Plugin\PluginManager->registerPackage(Object(Composer\Package\CompletePackage))
#4 /src/test/vendor/composer/composer/src/Composer/Plugin/PluginManager.php(76): Composer\Plugin\PluginManager->loa in /src/test/vendor/dealerdirect/phpcodesniffer-composer-installer/src/Plugin.php on line 118
Script composer run post-install-message handling the post-update-cmd event returned with error code 255

It has been crossposted to PHPCSStandards/composer-installer#59

Thanks

`wp --require=bad-command.php package list` test failure

The test Run package commands early, before any bad code can break them currently fails:

02. $ wp --require=bad-command.php package list
    
    Error: Doing it wrong.
    cwd: /tmp/wp-cli-test-run-591f3273a0a696.15977475/
    exit status: 1
    In step `When I run `wp --require=bad-command.php package list`'.               # vendor/wp-cli/wp-cli/features/steps/when.php:29
    From scenario `Run package commands early, before any bad code can break them'. # vendor/wp-cli/package-command/features/package.feature:43
    Of feature `Manage WP-CLI packages'.                                            # vendor/wp-cli/package-command/features/package.feature

I think the package family of commands should be added to the list of protected commands.

Refresh README.md

#32 (comment)

Package name is retrieved from wrong branch

The code to fetch the composer.json file for retrieving the package name is currently hardcoded against the master branch:

package-command/src/Package_Command.php

Line 957 in 8ac1e64

$raw_content_url = 'https://raw.githubusercontent.com/' . $package_name . '/master/composer.json';

It should reuse the actual branch that was requested to be installed instead.

Adopt and enforce new `WP_CLI_CS` standard

We have a new PHPCS standard for WP-CLI called WPCliCS (props @jrfnl). It is part of the wp-cli/wp-cli-tests package starting with version v2.1.0.

To adopt & enforce this new standard, the following actions need to be taken for this repository:

• Create a PR that adds a custom ruleset phpcs.xml.dist to the repository

  • Add phpcs.xml.dist file
  • Adapt .distignore to ignore phpcs.xml.dist & phpunit.xml.dist
  • Adapt .gitignore to ignore phpunit.xml, phpcs.xml & .phpcs.xml
  • Require version ^2.1 of the wp-cli/wp-cli-tests as a dev dependency

• Make any required changes to the code that fail the checks from the above ruleset in separate PRs

• Merge thre ruleset once all required changes have been processed and merged

A sample PR for a simple repository can be seen here: https://github.com/wp-cli/maintenance-mode-command/pull/3/files

Related wp-cli/wp-cli#5179

Switch back to `wp-cli/wp-cli:*` when 1.2.0 is released.

As soon as WP-CLI v1.2.0 has been released, we should revert #16 .

Compatibility with Composer 2

Hi,

Hello everyone. Thanks for your work, I appreciate it very much.

I would like to adapt my composer.json to Composer 2. For testing purposes I have created a very simple composer.json file:

{
  "name": "gbiorczyk/my-package",
  "require-dev": {
    "composer/composer": "^2.0"
  }
}

And then I execute the following command:

composer require wp-cli/package-command

And I have such errors:

sing version ^2.0 for wp-cli/package-command
./composer.json has been updated
Running composer update wp-cli/package-command
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - wp-cli/package-command v2.0.0 requires composer/composer ^1.2.0 -> found composer/composer[1.2.0, ..., 1.10.17] but it conflicts with your root composer.json require (^2.0).
    - wp-cli/package-command[v2.0.1, ..., v2.0.7] require composer/composer >=1.2.0 <1.7.0 || ^1.7.1 -> found composer/composer[1.2.0, ..., 1.10.17] but it conflicts with your root composer.json require (^2.0).
    - Root composer.json requires wp-cli/package-command ^2.0 -> satisfiable by wp-cli/package-command[v2.0.0, ..., v2.0.7].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Do you plan on compatibility with Composer 2? If so, when can this be expected? I will be very grateful for your answer!

With best wishes,
Mateusz Gbiorczyk

Document support for GITHUB_TOKEN

#47 added support for the GITHUB_TOKEN and COMPOSER_AUTH env. But it's not documented.

I think we should mention the support on the wp package install command so it's visible on https://developer.wordpress.org/cli/commands/package/install/.

Allowed memory size exhausted while installing package

Here is the output of wp package install wp-cli/scaffold-package-command:

Installing package wp-cli/scaffold-package-command (dev-master)
Updating /Users/apple/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 9437184 bytes) in /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php on line 565
PHP Stack trace:
PHP   1. {main}() /Users/apple/code/rtcamp/wp-cli/php/boot-fs.php:0
PHP   2. include_once() /Users/apple/code/rtcamp/wp-cli/php/boot-fs.php:17
PHP   3. WP_CLI\bootstrap() /Users/apple/code/rtcamp/wp-cli/php/wp-cli.php:23
PHP   4. WP_CLI\Bootstrap\LaunchRunner->process() /Users/apple/code/rtcamp/wp-cli/php/bootstrap.php:75
PHP   5. WP_CLI\Runner->start() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php:23
PHP   6. WP_CLI\Runner->do_early_invoke() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:1047
PHP   7. WP_CLI\Runner->_run_command_and_exit() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:83
PHP   8. WP_CLI\Runner->run_command() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:376
PHP   9. WP_CLI\Dispatcher\Subcommand->invoke() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:353
PHP  10. call_user_func:{/Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425
PHP  11. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425
PHP  12. call_user_func:{/Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89
PHP  13. Package_Command->install() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89
PHP  14. Composer\Installer->run() /Users/apple/code/rtcamp/wp-cli/vendor/wp-cli/package-command/src/Package_Command.php:335
PHP  15. Composer\Installer->doInstall() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:226
PHP  16. Composer\Installer->processDevPackages() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:466
PHP  17. Composer\DependencyResolver\Pool->whatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:1002
PHP  18. Composer\DependencyResolver\Pool->computeWhatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Pool.php:193
PHP  19. Composer\Repository\ComposerRepository->whatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Pool.php:204
PHP  20. Composer\Repository\ComposerRepository->loadProviderListings() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:296
PHP  21. Composer\Repository\ComposerRepository->loadProviderListings() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:579
PHP  22. array_merge() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:565

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9437184 bytes) in /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php on line 565

Call Stack:
    0.0021     392888   1. {main}() /Users/apple/code/rtcamp/wp-cli/php/boot-fs.php:0
    0.0026     399720   2. include_once('/Users/apple/code/rtcamp/wp-cli/php/wp-cli.php') /Users/apple/code/rtcamp/wp-cli/php/boot-fs.php:17
    0.0029     410928   3. WP_CLI\bootstrap() /Users/apple/code/rtcamp/wp-cli/php/wp-cli.php:23
    0.1291    8158360   4. WP_CLI\Bootstrap\LaunchRunner->process() /Users/apple/code/rtcamp/wp-cli/php/bootstrap.php:75
    0.1291    8158400   5. WP_CLI\Runner->start() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php:23
    0.1294    8158888   6. WP_CLI\Runner->do_early_invoke() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:1047
    0.1296    8160016   7. WP_CLI\Runner->_run_command_and_exit() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:83
    0.1297    8160016   8. WP_CLI\Runner->run_command() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:376
    0.1298    8161192   9. WP_CLI\Dispatcher\Subcommand->invoke() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Runner.php:353
    0.1428    8563320  10. call_user_func:{/Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425
    0.1428    8563320  11. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:425
    0.1428    8564128  12. call_user_func:{/Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89}() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89
    0.1428    8564128  13. Package_Command->install() /Users/apple/code/rtcamp/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:89
    1.5352   16085968  14. Composer\Installer->run() /Users/apple/code/rtcamp/wp-cli/vendor/wp-cli/package-command/src/Package_Command.php:335
    1.5411   15661344  15. Composer\Installer->doInstall() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:226
   10.7699   19421536  16. Composer\Installer->processDevPackages() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:466
   10.7700   19422008  17. Composer\DependencyResolver\Pool->whatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Installer.php:1002
   10.7701   19422048  18. Composer\DependencyResolver\Pool->computeWhatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Pool.php:193
   10.7701   19422048  19. Composer\Repository\ComposerRepository->whatProvides() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Pool.php:204
   10.7701   19422048  20. Composer\Repository\ComposerRepository->loadProviderListings() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:296
   13.1998  127641904  21. Composer\Repository\ComposerRepository->loadProviderListings() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:579
   13.1998  127641904  22. array_merge() /Users/apple/code/rtcamp/wp-cli/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php:565

Reverted composer.json.

Unable to install packages on Windows and PHP7.3.1

Here is my WP CLI info:

OS:     Windows NT 10.0 build 17763 (Windows 10) i586
Shell:  C:\Windows\system32\cmd.exe
PHP binary:     D:\dev\xampp\php\php.exe
PHP version:    7.3.1
php.ini used:   D:\dev\xampp\php\php.ini
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       D:\dev
WP-CLI packages dir:    C:\Users\EDIT/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0

And here is the response when trying to install a package:

PS D:\dev> wp package install iandunn/wp-cli-rename-db-prefix
Installing package iandunn/wp-cli-rename-db-prefix (dev-master)
Updating C:\Users\EDIT\.wp-cli\packages\composer.json to require the package...
Error: Failed to get composer instance: The configured cafile was not valid or could not be read.
Reverted composer.json.

Everything else works, WP CLI is in D:\dev\wp-cli\ and PHP in D:\dev\xampp\php\ and both are set in PATH.

This is the content of D:\dev\wp-cli\wp.bat:

@ECHO OFF
php.exe "D:\dev\wp-cli\wp-cli.phar" %*

Thank you!

Short package identifiers should default to GitHub repos

In the context of our move to retire the package index, the behavior of the package manager should change.

When a shortened package identifier like <vendor>/<package> is being passed to wp package install, the package manager should first check whether that identifier exists within the package index (for backwards compatibility reasons), and if not, fall back to assuming this points to a corresponding GitHub repository in the form https://github.com/<vendor>/<package>.git.

Related: wp-cli/wp-cli#4236

Version requirements only work for the package index

The current parsing code that tries to identify the package only allows for version constraints when using the package index. For git repositories, it just fails with an Error: Invalid package..

Ideally, the parsing should accept any string that the underlying Composer would be able to handle, with a fallback to building a proper GitHub URL for shortened syntax to account for the package index deprecation.

Tests fail because utils/make-phar.php isn't accessible

See https://travis-ci.org/wp-cli/package-command/builds/209899744

01. $ php -dphar.readonly=0 'features/bootstrap/../../utils/make-phar.php' '/tmp/wp-cli-test-run-58c317feeaf023.95759079/wp-cli-build-58c317feeaff24.74413409.phar' --version='0.23.0' && chmod +x '/tmp/wp-cli-test-run-58c317feeaf023.95759079/wp-cli-build-58c317feeaff24.74413409.phar'
    Could not open input file: features/bootstrap/../../utils/make-phar.php

Which option makes more sense?

1. Include utils/make-phar.php as a one-off in this repo.
2. Add utils/make-phar.php to wp scaffold package-tests so that the Phar creation step is available to every WP-CLI command.
3. Add utils/make-phar.php to the generated WP-CLI Phar file, so that it's available

I'm leaning towards 3 at this point, so there's always one source of truth for Phar generation.

Don't use default Composer CA bundle if in phar as not included so won't work.

From original @swiffer wp-cli/wp-cli#4703

Running WP-CLI 1.5.0 I cannot install new commands via

wp package list / install

failed to open stream: phar error: "vendor/composer/ca-bundle/res/cacert.pem" is not a file in phar

As we don't include Composer's CA bundle in the phar the default "last resort" doesn't work CaBundle.php#L121 so should avoid it. Noticeable particularly on Windows as default paths searched by Composer won't usually find anything.

PR incoming.

Invalid require line can be left in composer.json if composer fails to run - this prevents further package installs

Setup

Mac running latest MacOS (Sierra 10.12.5) Composer v1.5.1 WP-CLI v1.3

Issue

If you run wp package install <package> and the package is not valid and composer fails for some reason (in my case it was out of memory) then .wp-cli/packages/composer.json is not reverted and the invalid package is left in the require section. This means that subsequent wp package installs will fail.

Can this be handled better?

Steps to reproduce

• Edit php.ini and set your memory_limit low so that composer update fails (mine failed with 128M)
• Run wp package install runcommand/dist-archive - this gave me the following output before running out of memory:

Installing package runcommand/dist-archive (dev-master)
Updating /Users/rosswintle/.wp-cli/packages/composer.json to require the package...
Registering [email protected]:runcommand/dist-archive.git as a VCS repository...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies

• Note that composer.json was not reverted and now contains an invalid package reference (as runcommand/dist-archive doesn't work for some reason
• Edit php.ini and set your memory_limit back to something higher
• Run wp package install runcommand/dist-archive - this runs right though until Error: Package installation failed (Composer return code 2). Reverted composer.json
• Realise that the package is now in a different place and run wp package install wp-cli/dist-archive-command - this fails because The requested package runcommand/dist-archive could not be found in any version, there may be a typo in the package name.
• All subsequent attempts to install a package fail because the incorrect package name is in the composer.json

This seems like an edge case, but I wonder if there are other cases where the requires section of composer.json may become invalid (if a package is deleted from GitHub, perhaps?) and prevent further package installs?

Declaration of WP_CLI\ComposerIO::isVerbose() and others not compatible with Composer\IO\NullIO::isVerbose(): bool

I understand that the bug has presented itself with the package commands (which are in a different repository), but the issue stems from the ComposerIO.php file in this repository.

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

Attempting to install a wp-cli package from the instructions listed here. Doing so results in the error:

PHP Fatal error:  Declaration of WP_CLI\ComposerIO::isVerbose() must be compatible with Composer\IO\NullIO::isVerbose(): bool in /app/vendor/wp-cli/wp-cli/php/WP_CLI/ComposerIO.php on line 16

Wp-cli package I'm attempting to install: https://github.com/gilzow/wp-graphql-jwt-authentication-wp-cli

Package was built according to the directions in the Commands Cookbook. Including the package in a plugin works as expected.

Output when trying to install:

$ wp package install https://github.com/gilzow/wp-graphql-jwt-authentication-wp-cli.git
Installing package gilzow/wp-graphql-jwt-authentication-wp-cli (dev-main)
Updating /var/www/.wp-cli/packages/composer.json to require the package...
Registering https://github.com/gilzow/wp-graphql-jwt-authentication-wp-cli.git as a VCS repository...
PHP Fatal error:  Declaration of WP_CLI\ComposerIO::isVerbose() must be compatible with Composer\IO\NullIO::isVerbose(): bool in /app/vendor/wp-cli/wp-cli/php/WP_CLI/ComposerIO.php on line 16

Fatal error: Declaration of WP_CLI\ComposerIO::isVerbose() must be compatible with Composer\IO\NullIO::isVerbose(): bool in /app/vendor/wp-cli/wp-cli/php/WP_CLI/ComposerIO.php on line 16
Reverted composer.json.

I also attempted to install the package as a zip file, and as a local directory. Error message remains the same.

Describe how other contributors can replicate this bug

see above.

Describe what you would expect as the correct outcome

Package should install or error indicating the root issue with installation.

Let us know what environment you are running this on

$ wp cli info
OS:     Linux 5.10.47-linuxkit wp-cli/wp-cli#1 SMP Sat Jul 3 21:51:47 UTC 2021 x86_64
Shell:  /bin/dash
PHP binary:     /usr/bin/php
PHP version:    7.4.23
php.ini used:   /etc/php/7.4-zts/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.1.48-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
SQL modes:      
WP-CLI root dir:        /app/.platform/local/deps/php/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      /app/.platform/local/deps/php/vendor
WP_CLI phar path:       
WP-CLI packages dir:    /var/www/.wp-cli/packages/
WP-CLI global config:   
WP-CLI project config:  /app/wp-cli.yml
WP-CLI version: 2.6.0

Provide a possible solution

After updating /vendor/wp-cli/wp-cli/php/WP_CLI/ComposerIO.php to match the signature from /vendor/composer/composer/src/Composer/IO/NullIO.php and tried installing again, it then errored:

PHP Fatal error:  Declaration of WP_CLI\ComposerIO::write($messages, $newline = true, $verbosity = self::NORMAL) must be compatible with Composer\IO\NullIO::write($messages, bool $newline = true, int $verbosity = self::NORMAL): void in /vendor/wp-cli/wp-cli/php/WP_CLI/ComposerIO.php on line 23

After updating that signature to match, it then complained about the signature for WP_CLI\ComposerIO::writeError. After updating that signature and trying again, THEN it successfully installed the above package.

Tests in `wp-cli/wp-cli` fail because of Composer conflict

Composer has a conflict between wp-cli/wp-cli@dev-master and wp-cli/[email protected] (See wp-cli/wp-cli#3933)

This should be resolvable through a proper branch alias of "dev-master": "1.x-dev".