box-project / box Goto Github PK

This requires more progress on the box ecosystem and tooling first but the idea would be to have an article similar to Matthieu Moquet which covers:

• how PHARs works in general
• common usage for PHARs
• common issues encountered when building a PHAR distributed application:
  • installer script
  • autoloading
  • requirement checks
  • PHAR build
  • update
  • autorelease

This should be the case.

• https://github.com/cmpayments/crate/pull/1/files
• https://wiki.debian.org/LSBInitScripts

See box-project/box2#138

Happening: since 3995ac0

Steps to reproduce:

composer global require 'humbug/php-scoper:^1.0@dev'
composer global require humbug/box:dev-master

After this composer global commands (even unrelated, like show -i) will fail with failed opening required(/home/weirdan/.composer/vendor/composer/../humbug/box/vendor/humbug/php-scoper/src/functions.php)

When box is installed globally (or as a dependency of some other project) it doesn't have vendor subfolder. It's dependencies are in sibling folders instead.

Suggested fix: put that file in autoload/files section of php-scoper, remove here.

Right now only the scoped files and the binary are dumped in the .box.

More informations regarding the binary for the app & co. could be inferred from it

Right now it will fail due to the missing .requirement-checker

The extension ext-phar will always be necessary for the PHAR and as such should be included in the requirements whether or not it is declared in the composer.json require section.

If the PHAR is compressed, the zip extension is also required, but it is likely that PHP will not be able to even execute it without it anyway so to be check if it's worth it or not

I've installed box globally via

$ composer global require humbug/box:^3.0@alpha

And when I run

$ box compile

inside a package directory containing a composer.json I receive the following error:

? Adding files               

In Factory.php line 287:
                                                                                                                      
  Composer could not find a composer.json file in /tmp/box/Box16095                                                   
  To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section

The directory where I run compile and in which I have box.json has a composer.json so I don't know what went wrong.

When building a PHAR (for prod usage) it is a good practice to sign it in which case a private key is necessary. The issue is that as soon as you configure box to do that, a contributor can no longer build a PHAR (for dev purposes).

I did a little trick with once relying on make and .dist file which was about copying the .dist file and removing the algorithm leveraging a Makefile rule but I'm not really happy with that solution.

Another solution IMO would be to pass a flag to the build command to say the PHAR built is for dev purposes and maybe append a piece of code somewhere so that when the PHAR is executed it will print a warning (unless in quiet mode) that the PHAR is not properly signed. Note that this shouldn't be needed for a prod PHAR as if the PHAR is signed, it cannot be executed without the public key.

Right now the blacklist is used as a filter for the other directory settings. It would be very useful however to just be able to do:

{
  "blacklist": ["dist"]
}

And this way just exclude the ./dist directory as well. Maybe being able to use globs could be cool too.

When running

$ composer global require humbug/box:^3.0@dev

I receive the following error

$ composer global require humbug/box:^3.0@dev
Changed current directory to /home/ojrask/.config/composer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - humbug/box 3.x-dev requires composer/xdebug-handler dev-master -> satisfiable by composer/xdebug-handler[dev-master] but these conflict with your requirements or minimum-stability.
    - humbug/box 3.0.0-alpha.1 requires composer/xdebug-handler dev-master -> satisfiable by composer/xdebug-handler[dev-master] but these conflict with your requirements or minimum-stability.
    - humbug/box 3.0.0-alpha.0 requires humbug/php-scoper ^1.0@dev -> satisfiable by humbug/php-scoper[1.0.x-dev] but these conflict with your requirements or minimum-stability.
    - Installation request for humbug/box ^3.0@dev -> satisfiable by humbug/box[3.0.0-alpha.0, 3.0.0-alpha.1, 3.x-dev].

Installation failed, deleting ./composer.json.

Running on Composer 1.6.4 and PHP 7.2.4.

This can be resolved by adding proper stability requirements to my global composer.json, yes? Would a note about dev stability be appropriate in installation instructions?

Untouched

• php-translation
• psh
• PHPUnit
• phpmetrics
• paragonie/random_compat
• phpbrew/Onion
• facile-it/paraunit
• maglnet/ComposerRequireChecker

In Progress

• deprecation-detector (#146)
• phpdoc-to-typehint (#34)
• symfonycorp/insight (#79)
• pdepend/pdepend (#372)
• sensiolabs/security-checker (will likely be a Go binary in the future)
• phpmd/phpmd [jakzal/phpmd#1]

Done

• box
• php-scoper
• infection
• psalm (#656)
• psysh (#488)
• deptrac (#178)
• laravel-zero/laravel-zero
• schema-generator
• doctrine/migrations (#691)
• phpstan
• llaville/php-reflect (#28)
• llaville/umlwriter (086fee15)
• llaville/php-compat-info (6faabf7)
• paratestphp/paratest (#386)
• cakephp/phinx (#1522)
• PHP-CS-Fixer (#3726)
• scrutinizer-ci/ocular(#43)
• dmytro-demchyna/schema-keeper
• phpro/grumphp
• phpDocumentor/phpDocumentor2
• phpbrew(#1082)

When used with PHP-Scoper however, which requires to dump the dependencies, throw an error

See box-project/box2#153

just an idea, please just close if you think the switch is not worth the effort.

beeing in the php world and using it on multiple platforms (linux, windows & mac) i personally prefer to stay in the php world if this is possible and a good choice.

my suggestion would be to switch away from the makefile to a robofile https://robo.li/ it is able to do the same thing. developers don't have to "learn" another syntax (yes i know it is not that difficult) and also have the power of php at hand.

Case with infection:

vendor/
  bin/
    broken-link -> removed package

Some configuration options are nullable or optional. The doc should be reworked to make that clear. The code should be checked as well to see how the schema validation works in those cases

To speed up things we are leveraging Amp to process the files in parallel. This is however very inconvenient for debugging as it's no longer possible to put a break point in the code executed in parallel.

@kelunik is there anything on Amp side for this? Otherwise I was thinking of replacing the parallel processing by a plain array_map...

There is placeholders available with box (@git_version) but I'm not sure exactly how they work and we had an issue with Humbug when we tried to include Ocramius/PackageVersions.

It might also be worth to check if we cannot completely switch to Ocramius/PackageVersions rather than custom stuff which looks simpler and has the advantage to not require any IO.

It looks when the PHP process is restarted to disable xdebug, xdebug is still enabled for the workers.

See amphp/parallel#47

When using Box without any files configuration:

• Build the PHAR
• Build the PHAR again: this is going to fail because the previous PHAR has been collected but is removed right after

• https://github.com/Elendev/ElendevPhar
• https://github.com/IcecaveStudios/near
• https://github.com/JeroenDeDauw/PharBuilder
• https://github.com/MacFJA/PharBuilder
• https://github.com/Modularr/Phar
• https://github.com/brad-jones/pharbuilder
• https://github.com/clue/phar-composer
• https://github.com/cmpayments/crate
• https://github.com/crodas/Phar-Builder
• https://github.com/index0h/yii2-phar
• https://github.com/keradus/PharBuilder
• https://github.com/kos33rd/pharaon
• https://github.com/laravel-zero/framework
• https://github.com/mauris/concrete
• https://github.com/mvccore/packager
• https://github.com/oleics/php-ac-build-phar
• https://github.com/parcel-bundler/parcel
• https://github.com/theseer/Autoload

Edit: some elements of the list are coming from MacFJA/PharBuilder#15

You are requiring ^1.0, here is the current last version: https://github.com/justinrainbow/json-schema/tree/5.2.6

I have installed box as a global binary via

$ composer global require humbug/box:^3.0@dev

and when I run

$ box compile

inside a project directory I get the following error:

? Adding requirements checker

In Finder.php line 547:      
                                                                                                                      
  The "/home/<user>/.config/composer/vendor/humbug/box/src/RequirementChecker/../../.requirement-checker" directory does not exist.

Box has worked before so I presume this has something to do with the project being initially built with box 2 and now version 3 has changed something. My box.json is as such:

{
    "main": "bin/mybin",
    "directories": ["src"],
    "finder": [
        {
            "name": "*.php",
            "exclude": ["tests"],
            "in": "vendor"
        }
    ],
    "git-version": "release_version",
    "output": "build/mybin.phar",
    "stub": true
}

This same error appears locally as well as in our CI tooling. I will disable requirements checking until I can find a solution for this. :)

Remove the shebang line from the binary (which is where it usually is). This should be in the stub instead

See box-project/box2#163

TL;DR

What is the SHA1 file hash of the released Box3 (box.phar) files?

How can I find the checksum of the Box3 (box.phar) file, downloaded from the releases page?

Or including checksums to the downloadable releases, something like:
https://github.com/syncthing/syncthing/releases/

TS; DR

Thanks for the effort of the humbug/box contributors to maintain the inherited wonderful 'box'.

I don't know if it's the right place to ask but I would like to know what the SHA1 file hash values of the released box.phar files are.

Since I use 'box.phar' a lot, I customized the conventional (box2's) installer and made an box3 installer of the latest release for my ease.

Though, the only left part was the checksum comparison between the remote and downloaded files.

I searched the repo but couldn't find the hash to compare.

So, where/how can I get the file hash value of the released box.phar file?
It doesn't have to be a SHA1 hash if it's something that can be verifiable.

P.S. I will close this issue if it's not a proper place to ask.

Thanks.

Current conlution (2018/04/29)

• There are no hash signatures provided as a checksum for downloads at this time.

• Meanwhile, provide them one's own way.

• Now brainstorming for better install processes.

• 2018/04/29 Changed issue title to
  "SHA1 hash value of box.phar file to verify" -> "Provide hash signatures for downloads/releases"

See box-project/box2#166

See box-project/box2#74

Potential informations missing:

• metadata
• compression algorithm
• time & memory taken
• size of the built PHAR

This needs some more benchmarking but I suspect that under a few thousand files even, if no compactor is enabled then starting the workers is likely to be a big useless overhead

box-project/box2#171

Attempted to follow installation instructions for a project-installation with bamarni/composer-bin-plugin as such:

$ composer require --dev bamarni/composer-bin-plugin
$ composer bin box require --dev humbug/box
# then inserted required commands to `post-install-cmd` and `post-update-cmd`
$ composer update # just in case

When attempting to run

$ vendor/bin/box help build

I receive the following error:

PHP Fatal error: Uncaught error: Class 'KevinGH\Box\Application' not found in /path/to/project/vendor-bin/box/vendor/humbug/box/bin/box:19

It seems like bamarni/composer-bin-plugin is not running composer install on packages properly as the humbug/box vendor directory is missing a vendor directory.

I will try and see if a global installation changes anything, but I would like to carry the dep as a local dep with the project to make CI build pipelines just a little simpler to set up.

See box-project/box2#137

As long as Box only supports CLIs, I think it would be cool to add a CLI checker: https://github.com/humbug/humbug/blob/master/bin/humbug#L4-L6

This could be done in the requirement checker for a nice output and to avoid a new option

running box on a firewalled windows system where all connections are blocked by default for all processes. if i run box build i get screens of error messages (i try to put a symfony4 skeleton in a phar file).

[ERROR] _HumbugBox5adef95163555\Amp\Process\ProcessException: Failed to connect socket #0: 10013: An attempt was made
         to access a socket in a way forbidden by its access permissions. in
         phar://C:/bin/box.phar/vendor/amphp/process/lib/Internal/Windows/SocketConnector.php:258
Stack trace:

if i allow the php process to create a connection the errors are gone and box is building. in comparision to box 2 the amp part has the opposite of a speed increase. what box2 has build in 63sec box3 was not able to do in over 30min. had to terminate the process, the firewall was configured to allowed php to access the local dynamic port and also the temp file ampCB1B.tmp was allowed to connect.

amp is a nice concept but it should be really optional, it has quite many side effects.

having to allow dynamic port access which i can't control was never i concept i liked. also having files in the temp dir, which are not firewalled is really uncool (need dynamic access). additional i have to bring my firewall in dialog mode every time i want to run box because the temp file is generated with a random name, so i have to create new rules for each file at each run.

please add a old school non-amp processing.

files:
   - composer.json
directories:
   - bin
   - config
   - src
   - lib
finder:
   -
     name: '*.*'
     in: vendor
     exclude:
       - .gitignore
       - .md
       - phpunit
       - Tester
       - Tests
       - tests
compactors:
   - Herrera\Box\Compactor\Json
   - Herrera\Box\Compactor\Php
compression: GZ
main: bin/puppet-enc
output: build/puppet-enc.phar
stub: true
git-commit: git_commit
git-version: git_version
git-tag: git_tag
chmod: '0755'

box build
converting to json


[WARNING] The command "build" is deprecated. Use "compile" instead.



   ____
  / __ )____  _  __
 / __  / __ \| |/_/
/ /_/ / /_/ />  <
/_____/\____/_/|_|


Box version 3.0.0-alpha.3 build 6b7dc4a883c199c93403adbc7dfaefdd52fc9336


// Loading the configuration file
// "box.json".

Building the PHAR "./build/puppet-enc.phar"
? Setting replacement values
 + @git_commit@: 5f620495beb07c9304e4bd88dafa11e45224b1c5
 + @git_tag@: 1.0.1
 + @git_version@: 1.0.1
? Registering compactors
 + KevinGH\Box\Compactor\Json
 + KevinGH\Box\Compactor\Php
? Adding main file: ./bin/puppet-enc
? Adding requirements checker
? Adding binary files
   > No file found
? Adding files


[ERROR] _HumbugBox5adef95163555\Amp\Process\ProcessException: Failed to connect socket #0: 10013: An attempt was made
        to access a socket in a way forbidden by its access permissions. in
        phar:///bin/box.phar/vendor/amphp/process/lib/Internal/Windows/SocketConnector.php:258
Stack trace:
#0
        phar:///bin/box.phar/vendor/amphp/amp/lib/Loop/NativeDriver.php(91):
        _HumbugBox5adef95163555\Amp\Process\Internal\Windows\SocketConnector->onProcessConnectTimeout('bo',
        Object(_HumbugBox5adef95163555\Amp\Process\Internal\Windows\Handle))
#1
        phar:///bin/box.phar/vendor/amphp/amp/lib/Loop/Driver.php(121):
        _HumbugBox5adef95163555\Amp\Loop\NativeDriver->dispatch(true)
#2
        phar:///bin/box.phar/vendor/amphp/amp/lib/Loop/Driver.php(69):
        _HumbugBox5adef95163555\Amp\Loop\Driver->tick()
#3
        phar:///bin/box.phar/vendor/amphp/amp/lib/Loop.php(76):
        _HumbugBox5adef95163555\Amp\Loop\Driver->run()
#4
        phar:///bin/box.phar/vendor/amphp/amp/lib/functions.php(151):
        _HumbugBox5adef95163555\Amp\Loop::run(Object(Closure))
#5 phar:///bin/box.phar/src/Box.php(264):
        _HumbugBox5adef95163555\Amp\Promise\wait(Object(_HumbugBox5adef95163555\Amp\Coroutine))
#6
        phar:///bin/box.phar/src/Box.php(153): _HumbugBox5adef95163555\KevinGH\Box\Box->processContents(Array,
        '...')
#7 phar:///bin/box.phar/src/Console/Command/Compile.php(222):
        _HumbugBox5adef95163555\KevinGH\Box\Box->addFiles(Array, false, true)
#8
        phar:///bin/box.phar/src/Console/Command/Compile.php(140):
        _HumbugBox5adef95163555\KevinGH\Box\Console\Command\Compile->addFiles(Object(_HumbugBox5adef95163555\KevinGH\Bo
        x\Configuration), Object(_HumbugBox5adef95163555\KevinGH\Box\Box),
        Object(_HumbugBox5adef95163555\KevinGH\Box\Console\Logger\BuildLogger),
        Object(_HumbugBox5adef95163555\Symfony\Component\Console\Style\SymfonyStyle))
#9
        phar:///bin/box.phar/src/Console/Command/Compile.php(124):
        _HumbugBox5adef95163555\KevinGH\Box\Console\Command\Compile->createPhar(Object(_HumbugBox5adef95163555\KevinGH
        Box\Configuration), Object(_HumbugBox5adef95163555\Symfony\Component\Console\Input\ArgvInput),
        Object(_HumbugBox5adef95163555\Symfony\Component\Console\Output\ConsoleOutput),
        Object(_HumbugBox5adef95163555\KevinGH\Box\Console\Logger\BuildLogger),
        Object(_HumbugBox5adef95163555\Symfony\Component\Console\Style\SymfonyStyle), false)
#10
        phar:///bin/box.phar/vendor/symfony/console/Command/Command.php(225):
        _HumbugBox5adef95163555\KevinGH\Box\Console\Command\Compile->execute(Object(_HumbugBox5adef95163555\Symfony\Com
        ponent\Console\Input\ArgvInput),
        Object(_HumbugBox5adef95163555\Symfony\Component\Console\Output\ConsoleOutput))
#11
        phar:///bin/box.phar/src/Console/Command/Build.php(34):
        _HumbugBox5adef95163555\Symfony\Component\Console\Command\Command->run(Object(_HumbugBox5adef95163555\Symfony\C
        omponent\Console\Input\ArgvInput),
        Object(_HumbugBox5adef95163555\Symfony\Component\Console\Output\ConsoleOutput))
#12
        phar:///bin/box.phar/vendor/symfony/console/Application.php(753):
        _HumbugBox5adef95163555\KevinGH\Box\Console\Command\Build->run(Object(_HumbugBox5adef95163555\Symfony\Component
        \Console\Input\ArgvInput), Object(_HumbugBox5adef95163555\Symfony\Component\Console\Output\ConsoleOutput))

Note: the description has been edited to go through the issue more easily.

The goal here is to be able to generate a installer file a la Composer (cf. Composer installer.php) which:

• Is compatible with low and restricted PHP environments in order to run the appropriate checks
• Checks the environments (like the requirement checker itself) to know if the PHAR being installed can be used in the current environment and fail gracefully if cannot
• Download the PHAR over HTTPS & potentially run a signature check a la phar.io (to be checked if some code from it can be re-used from there)

Original description:

Also requires to have the dependencies checked like done in PHP-Scoper

See box-project/box2#154

See box-project/box2#162

exists path like: 'E:\workenv\php-docker.......'

Excuse me, how to clear there are path prefix?

I'm not really familiar with the subject so this is more as a note if someone more of an expert can give his input and meanwhile doing some research.

From what I've seen so far:

• Signing your PHAR:
  • Rob Peck blogpost
  • Matthew Weier O'Phinney blogpost
• Singing a PHAR might not be enough: Sucuri blogpost. Might be worth checking this as well.
• Investigate more

It would also be good to have an audit/review at some point by an actual expert.

Idea got thanks to @jakzal: when a PHAR is being build with Box and a dev dependency is found, a warning should be given to the user. Indeed there is zero benefit to include them and on the contrary it's more dangerous than anything. Just to give a few reasons:

• They are useless
• It increases the PHAR size
• This may have a performance impact when running the PHAR
• It has a performance impact on the building time (as they are more files...)
• You potentially open a vector of attack as dev dependencies are not always built with security in mind (and neither should they be: they are meant for dev not production)

For each php script, the right autoload file needs to be found and depends in all of the following cases:

• Locally in the project
• As a dependency via Composer
• Globally, as a dependency via composer
• Handle the special case where the composer.json found is not an actual file but a symlink (likely to cause issues with realpath()
• Case where the ext phar is not installed
• Case where the autoload file is different, e.g. src/autoload.php instead of vendor/autoload.php
• In a PHAR

Update the following projects (among others) accordingly:

• box (this one)
• php-scoper
• infection
• phpstan
• PHP-CS-Fixer
• psysh
• PHPUnit
• schema-generator
• phpdoc-to-typehint
• php-translation

Unlike when installing a dependency with Composer, no constraint check is done when installing/using a PHAR. It can be done in an installer but then it's easy to miss it if downloading the PHAR directly, keeping the PHAR around and updating it or copying it from somewhere.

An attempt has been made in PHP-Scoper: link based on Symfony's requirement checker. It however has a few drawbacks:

• It is limited to checking extensions and the PHP platform (which can be fine) but don't take into consideration polyfills. A possible solution could be to look if a polyfill is included as well and ignore the extension requirement if it is
• As of now it only checks the project composer.json and don't account for the dependencies composer.json files which is silly
• There is a lot of boilertemplate due to the fact that it may run on unsupported PHP version. In the case of PHP-Scoper for example, that part is compatible with PHP 5.6 even though the project requires PHP7.1 to be able to provide a nice error message when running on PHP 5.6 instead of crashing with a weird error (which is the whole point of that checker except it's not limited to PHP versions). I however didn't check much more if it could be made more re-usable or something so to be investigated to try to make it simpler.

Edit: Composer 1.6.0 added a check-platform-reqs, I think it's worth checking it out

Because of some incompatible settings, one setting may be ignored. For example requirements checker cannot be used without stub to true. However I think that bailing out would be a bad UX, instead a warning could be displayed

The requirement checker currently extension based polyfills. In other words, if the project or a dependency requires a certain extension, when it is declared in their composer.json files like so:

{
    "require": {
         "ext-mcrypt": "*",
         "ext-mbstring": "*"
    }
}

The requirement checker will be able to pick those requirements. It also supports a range of polyfills. So with the example above, if phpseclib/mcrypt_compat is found in the installed dependencies (not as a dev dependency), the extension mcrypt will actually not be required. Likewise, if symfony/polyfill-mbstring is found, it will not require ext-mbstring.

However no function support is currently provided. For example if the project requires the Intl grapheme_* functions, there is no way to tell the requirement checker that those functions are required and that they are not if the symfony/polyfill-intl-grapheme package is installed