Consider removing package-command from the bundle

[ju1ius]

Given a wodpress project using composer to manage dependencies.
Running composer require wp-cli/wp-cli-bundle results in the following dependency tree:

composer show --tree wp-cli/wp-cli-bundle

wp-cli/wp-cli-bundle v2.10.0
├──wp-cli/cache-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/checksum-command ^2.1
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/config-command ^2.1
│  ├──wp-cli/wp-cli ^2.5
│  └──wp-cli/wp-config-transformer ^1.2.1
├──wp-cli/core-command ^2.1
│  ├──composer/semver ^1.4 || ^2 || ^3
│  └──wp-cli/wp-cli ^2.5.1
├──wp-cli/cron-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/db-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/embed-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/entity-command ^2
│  └──wp-cli/wp-cli ^2.10
├──wp-cli/eval-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/export-command ^2
│  ├──nb/oxymel ~0.1.0
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/extension-command ^2.1
│  ├──composer/semver ^1.4 || ^2 || ^3
│  └──wp-cli/wp-cli ^2.10
├──wp-cli/i18n-command ^2
│  ├──eftec/bladeone 3.52
│  ├──gettext/gettext ^4.8
│  │  ├──gettext/languages ^2.3
│  ├──mck89/peast ^1.13.11
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/import-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/language-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/maintenance-mode-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/media-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/package-command ^2.1
│  ├──composer/composer ^1.10.23 || ^2.2.17
│  │  ├──composer/ca-bundle ^1.0
│  │  ├──composer/class-map-generator ^1.0
│  │  │  ├──composer/pcre ^2.1 || ^3.1
│  │  │  └──symfony/finder ^4.4 || ^5.3 || ^6 || ^7
│  │  ├──composer/metadata-minifier ^1.0
│  │  ├──composer/pcre ^2.1 || ^3.1
│  │  ├──composer/semver ^3.2.5
│  │  ├──composer/spdx-licenses ^1.5.7
│  │  ├──composer/xdebug-handler ^2.0.2 || ^3.0.3
│  │  │  ├──composer/pcre ^1 || ^2 || ^3
│  │  │  └──psr/log ^1 || ^2 || ^3
│  │  ├──justinrainbow/json-schema ^5.2.11
│  │  ├──psr/log ^1.0 || ^2.0 || ^3.0
│  │  ├──react/promise ^2.8 || ^3
│  │  ├──seld/jsonlint ^1.4
│  │  ├──seld/phar-utils ^1.2
│  │  ├──seld/signal-handler ^2.0
│  │  ├──symfony/console ^5.4.11 || ^6.0.11 || ^7
│  │  │  ├──symfony/polyfill-mbstring ~1.0
│  │  │  ├──symfony/service-contracts ^2.5|^3
│  │  │  │  └──psr/container ^1.1|^2.0
│  │  │  └──symfony/string ^6.4|^7.0
│  │  │     ├──symfony/polyfill-ctype ~1.8
│  │  │     ├──symfony/polyfill-intl-grapheme ~1.0
│  │  │     ├──symfony/polyfill-intl-normalizer ~1.0
│  │  │     └──symfony/polyfill-mbstring ~1.0
│  │  ├──symfony/filesystem ^5.4 || ^6.0 || ^7
│  │  │  ├──symfony/polyfill-ctype ~1.8
│  │  │  └──symfony/polyfill-mbstring ~1.8
│  │  ├──symfony/finder ^5.4 || ^6.0 || ^7
│  │  ├──symfony/polyfill-php73 ^1.24
│  │  ├──symfony/polyfill-php80 ^1.24
│  │  ├──symfony/polyfill-php81 ^1.24
│  │  └──symfony/process ^5.4 || ^6.0 || ^7
│  └──wp-cli/wp-cli ^2.8
├──wp-cli/rewrite-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/role-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/scaffold-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/search-replace-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/server-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/shell-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/super-admin-command ^2
│  └──wp-cli/wp-cli ^2.5
├──wp-cli/widget-command ^2
│  └──wp-cli/wp-cli ^2.5
└──wp-cli/wp-cli ^2.10.0
   ├──mustache/mustache ^2.14.1
   ├──symfony/finder >2.7
   ├──wp-cli/mustangostang-spyc ^0.6.3
   └──wp-cli/php-cli-tools ~0.11.2

That's 64 packages, 30 of which are wp-cli/* packages.
Of the remaining 34, 20 are only required by the wp-cli/package-command whose sole dependency outside of wp-cli/wp-cli is... composer/composer 🤨

From its documentation, the purpose of wp-cli/package-command is to manage globally installed wp-cli commands.

Why would someone installing wp-cli-bundle inside a project need/want a command to manage global wp-cli packages? Moreover, since said packages are just composer packages, why can't they just be installed with composer?

IMO, running composer require some/package should not end up installing composer inside the project's vendor directory.

It seems to me that the package command should be moved in the suggests section of the bundle's composer.json, and only included by default in the phar release.

And even then I highly doubt the usefulness of this command, so maybe it should just be deprecated then removed like the package index.

As a side note, removing this command would remove the largest source of dependency conflicts (see #5920, #5916, wp-cli/wp-cli-bundle#606, wp-cli/wp-cli-bundle#558, wp-cli/wp-cli-bundle#348, etc).

[swissspidy]

Thanks for opening this issue and taking the time to look for similar ones & linking to them! Right now #5920 is probably the best place to consolidate the discussion and share ideas like this.

Why would someone installing wp-cli-bundle inside a project need/want a command to manage global wp-cli packages?

In a Composer project you would usually only install the individual the commands that you need for the project, not the whole bundle.

Moreover, since said packages are just composer packages, why can't they just be installed with composer?

That's possible & probably what you should do in your scenario :-)

And even then I highly doubt the usefulness of this command, so maybe it should just be deprecated then removed like the package index.

The wp package command is essential for allowing you to install other people's commands that they've built. We can't just remove that, because then you can't install other commands.

[ju1ius]

In a Composer project you would usually only install the individual the commands that you need for the project, not the whole bundle.

Fair enough, so in order to have the «most common commands», instead of composer require wp-cli/wp-cli-bundle, I should do composer require wp-cli/wp-cli wp-cli/cache-command wp-cli/config-command wp-cli/core-command wp-cli/cron-command wp-cli/db-command wp-cli/entity-command wp-cli/eval-command wp-cli/export-command wp-cli/extension-command wp-cli/i18n-command wp-cli/import-command wp-cli/language-command wp-cli/maintenance-mode-command wp-cli/media-command wp-cli/rewrite-command wp-cli/role-command wp-cli/scaffold-command wp-cli/search-replace-command wp-cli/shell-command wp-cli/widget-command.

In this case what's the point of the bundle?

The wp package command is essential for allowing you to install other people's commands that they've built. We can't just remove that, because then you can't install other commands.

Sorry, I'm having a hard time understanding the reasoning behind all this.
How is it essential if the exact same functionality can be reproduced by just using composer?
In what scenario is it impossible to replace wp package install with composer require?

[swissspidy]

In what scenario is it impossible to replace wp package install with composer require?

When you install/use WP-CLI via the Phar for example.

[ju1ius]

When you install/use WP-CLI via the Phar for example.

$ wp-cli.phar help rest
Error: 'rest' is not a registered wp command. See 'wp help' for available commands.

$ composer require -q wp-cli/restful && wp-cli.phar help rest
NAME

  wp rest

SYNOPSIS

  wp rest <command>

SUBCOMMANDS

  Contact
  Count
  Install
  ...

🤷🏻

[ju1ius]

Anyway, disregarding whether it is desirable or not for wp-cli to reinvent the wheel of package management in the phar release, wp-cli/wp-cli-bundle is currently the recommended way to install wp-cli with composer and in this case it makes zero sense for the bundle to pull-in composer itself as a dependency.

If the purpose of wp-cli/wp-cli-bundle is to package all commands for building the phar release, then its usage should be discouraged in composer-based projects, and the guide should be updated accordingly.

[danielbachhuber]

I'm open to the idea of only including wp-cli/package-command in the distributed Phar, and removing it as a dependency for wp-cli/wp-cli-bundle. This seems like a rather elegant solution to the problem of conflicts.

I added this to the 3.0.0 milestone for consideration.