Remove support for Phar archives

[scribu]

Bundling WP-CLI into a Phar archive was an interesting experiment, but it's become unnecessary since the introduction of the installer script: wp-cli/wp-cli.github.com#5

Also:

• can't install bash completions
• can't easily hack on WP-CLI files

We'll keep http://wp-cli.org/builds/phar/wp-cli.phar for a while, but it won't be updated anymore.

[DavertMik]

Hi, I'm the guy from @Codeception twitter.

Let me oppose. Phar is great stuff when you want to get things up and running. Especially If you don't need bash completions, and hack files. That happens when you use wp-cli as automation tool for Continuous Integration stuff, deployment scripts, etc.

For this cases

• we don't need global install
• we don't need redownload all packages by their own
• we don't need completions
• we don't need file changes
• we just need to grab it, and execute it locally.

Btw, this is highly insecure to pipe an external resource to bash.

Here is how I used @wp-cli in Travis-CI setup script: https://github.com/Codeception/WordPress-plugin-testing/blob/master/setup.sh Maybe I did smth wrong, but I'd really like to simplify that 3 initialization lines into one.

Anyway, building and maintaining phar is not a hard task. In Codeception we use the phar version as primary, because it's much easier for newbies and for portability. So I think it's a good idea to leave phar as an option.

[scribu]

Btw, this is highly insecure to pipe an external resource to bash.

It's not more insecure than downloading a binary file (.phar) and executing it.

Anyway, I agree that a Phar file would make more sense, for your usecase.

Anyway, building and maintaining phar is not a hard task.

It kind of is, when you're using Composer heavily:

• have to write a custom autoloader
• have to sort between dev dependencies and runtime dependencies

[DavertMik]

It kind of is, when you're using Composer heavily.

Really not a problem. You may still use Composer to load all the dependencies but then you just pack all the vendors into phar. Probably you will need a compiler class like this one: https://github.com/Codeception/Codeception/blob/master/package/Compiler.php

[scribu]

You may still use Composer to load all the dependencies but then you just pack all the vendors into phar.

Not if we want to allow users to install additional Composer packages. If WP-CLI was distributed as a Phar archive, we'd have to have two autoloaders and two composer.json files:

The one compiled into the Phar archive and a separate one inside ~/.wp-cli, which users can modify.

Related: #602

[DavertMik]

Phar is optional distribution. If user wants to install additinal package,
better way to do it via Composer.
If there is no purpose in using Composer, then phar is quite enough.

2013/8/9 Cristi Burcă notifications@github.com

You may still use Composer to load all the dependencies but then you just
pack all the vendors into phar.

Not if we want to allow users to install additional Composer packages. If
WP-CLI was distributed as a Phar archive, we'd have to have two autoloaders
and two composer.json files:

The one compiled into the Phar archive and a separate one inside ~/.wp-cli,
which users can modify.

Related: #602 #602

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/439#issuecomment-22395378
.