WP-CLI as a backend for steps

How many of WP-CLI commands could Blueprints reuse instead of reinventing the same logic?

• plugin install
  • Could potentially power the installPlugin step
  • Accepts a plugin slug, a path to a local zip file, or a URL to a remote zip file.
• config set – could power the defineWpConfigConsts step
• core multisite-convert – could power the enableMultisite step
• config shuffle-salts
• export and import – could handle WXR processing
• language – we could support installing language packs
• server – could potentially run the server on native PHP and maybe in Node.js
• theme, plugin, user
• scaffold post types, taxonomies etc code generation

Discussion

• Should all Blueprint steps become just plugins to wp-cli?
  • No, simple steps like cp, mv etc don't warrant loading the entire wp-cli machinery and could be handled higher up in the stack.
• Should all wp-cli commands be available as Blueprint steps?
  • It seems like a bad idea. This would inflate the scope, tightly couple the Blueprint library to wp-cli, and require inventing ways to express shell commands as JSON.
• Let's handle all downloads outside of WP-CLI. WP-CLI is sequential in nature (download plugin X, then download plugin Y), and Blueprints need to parallelize the downloads (download plugins X and Y at the same time).

cc @schlessera @swissspidy @danielbachhuber

Start with the linked WP-CLI command documentation and the discussion about plugins, downloads, and shell commands. Done means reaching and documenting an agreed, bounded integration scope for Blueprint steps rather than exposing every WP-CLI command.