Add support to force extracting archives

[smartinm]

Refs #10

[smartinm]

Added new option force-extract to build command:

$ phar-composer help build

Usage:
 build [-x|--force-extract] [path] [target]
Arguments:
 path                  Path to project directory or composer.json (default: ".")
 target                Path to write phar output to (defaults to project name)
Options:
 --force-extract (-x)  Enforce extracting the phar to a temporary directory.
 ...

[clue]

Thanks for this PR! 👍 The changes look good to me, and I'd like to see this included soon :)

Once we support this option, we should probably also consider to add a config key (extra.phar.force-extract ?), which defaults to false and can be overridden by the CLI option.

Also, would you care to add a note to the README.md and CHANGELOG.md?

Thanks!

[smartinm]

Hi, pull request updated based on your comments, please review :)

[clue]

Really great! 👍 The changes looks really good, and I'm perfectly happy with merging them as-is.

One minor thing I'm concerned with is (again.. sigh) naming :) Personally, I'm a bit undecided about the name "force-extract". It certainly describes what is does, but it doesn't really convey when to use this option. Can we come up with a better name?

Other than that, your changes look really good. Thanks for your input!

[smartinm]

I agree, how about "self-extracting" name? e.g.:

--self-extracting option allow to create a self-extracting phar archive. ?

[clue]

Way better!

This is actually a tricky one, given that the stub file always includes the Extractor. This is done for platforms which to not have the ext-phar enabled. This will degrade performance for them, but at least allow them to still run the phar.

Now what this option does is that is always enforces to use the Extractor, no matter whether the ext-phar is enabled or not. This is useful in the situation where there's absolutely no way to run the script from within a phar because it relies on filesystem paths (chmod(), realpath(), chdir() etc.)

So in fact each phar is always "self-extracting". So far I'm also having some trouble finding the right wording either, which highlights this subtle nuance :)

[clue]

Disregard my previous comment :)

how about "self-extracting" name?

Unless we can come up with a better name, I'm okay with it. I'd just like to merge this soon.

Would you care to update the docs accordingly?

[smartinm]

After reading your comment, I understand that "self-extracting" name can also be confusing...

Maybe an option to control the use of the php-box Extract class?

 --custom-extractor  Uses a custom phar extractor class: no, yes, force (default: yes)

• --custom-extractor=no not embeds Extract class from php-box (uses phar-extension extract)
• --custom-extractor=yes embeds Extract class from php-box and uses it whether the ext-phar is not enabled
• --custom-extractor=force embeds Extract class from php-box and always uses it

[clue]

Your changeset looks good to and I'd love to finally get this in! :)

How about an --extract=force option which defaults to yes/true for maximum compatibility that can explicitly be disabled with no/false?

[clue]

Your changeset looks good to and I'd love to finally get this in! :)

Ping @smartinm, is there anything I can help you with? :)

[hopeseekr]

All of the work in this PR is now in PR #83, with the conflicts resolved.