Include/require errors

[EvanK]

I'm not certain this project is still maintained, but I've tried using it to generate several phars, and they all build (and even install) successfully...but when executed, they print a bunch of warnings, and finally die with a fatal error trying to load classes from their vendor dependencies:

https://gist.github.com/EvanK/2c3f9ca429d995ea0989

Any clue what's causing this? I've tried with several packages, including phpunit and paratest

[clue]

Thanks for reporting this @EvanK!

This project is still maintained and in use, as such your above examples should have worked.. I'll look into this and post back in this ticket.

[clue]

Hi @EvanK, unfortunately I can't produce the problem you're seeing. I've just verified that the test suite and building several phars (among others phpunit and phar-composer itself) does work as expected.

Can you please provide some detailed steps to reproduce this, i.e. which versions of which component (PHP, phar-composer, distribution etc.) you're using?

Also, perhaps you can share/upload/email the supposedly invalid phars?

[EvanK]

Including a gist of the steps taken, from installing phar-composer to building the phpunit phar to using it:

https://gist.github.com/EvanK/aef3bc5f57a9d3d8a5ae

From the warnings and ultimate fatal error, it looks like its trying to load the vendor deps from the present working directory, instead of from the phar itself?

I've also put the resulting phar here on dropbox.

Thanks!

[hakre]

Phpunit as composer dependency operates on include path configuration. Perhaps that kind of autoloading isn't supported until the autoloader has been generated? And the autoloader isn't generated nor included which is why the include and requires then fail?

[clue]

Not sure what's happening here, running the same steps locally (pretty basic Ubuntu 14.04) does work fine…

I'll see if there's anything wrong with the resulting phar…

Perhaps anybody else happens to have any ideas?

[mikey179]

I had a similar problem when I switched from a global PHPUnit install (via PEAR) to a project-wise PHPUnit install (via Composer) and had to explicitly remove the include_path pointing to the global PHPUnit installation so that PHPUnit classes are loaded via the classloader generated by Composer, and not via the include path.

[EvanK]

@mikey179 The project on which I was trying to use my generated phar has a composer installed version of phpunit (which is brought in as a dependency of something else).

It could very well be that the phar is finding and including those composer-installed deps instead of the ones included in the phar.

How would you even work around something like that?

[clue]

I'll see if there's anything wrong with the resulting phar…

The resulting phar works just fine locally, so I suppose this must be an issue with your local PHP environment.

@mikey179 The project on which I was trying to use my generated phar has a composer installed version of phpunit (which is brought in as a dependency of something else).

This should already be supported: Packages from require-dev are simply ignored (see also #37) and should not interfere with your bundled phars. I've just confirmed that your linked phpunit.phar works just fine in a project that has phpunit installed via require-dev.

I'm not sure what else we could to here..

[clue]

had to explicitly remove the include_path…

Haven't used PEAR in years, but perhaps this might help?

[EvanK]

I built the phar in a tmp directory of a fresh vagrant machine, installed said phar in /usr/local/bin, then I changed to a separate project directory (that uses composer for its dependencies), and invoked it from there, where the same issue is manifesting.

So, it looks like regardless of where the phar was built, invoking it against a project that has another phpunit as a composer dep is causing the issue...I suspect it's finding the vendor/autoload.php in the working directory and trying to use it instead of the deps that are already bundled into the phar.

I've no idea how to work around it, but it does seem to be an include path/composer issue rather than specifically phar-composer

[clue]

Just to make sure we're talking about the same thing:

# example project that uses require-dev for phpunit:
$ git clone git@github.com:clue/graph.git
$ cd graph
$ composer install

# does work with require-dev
$ ./vendor/bin/phpunit

# does work with your composer.phar
$ php phpunit.phar

# does work with global installation
$ phar-composer install phpunit/phpunit
$ phpunit

Can you reproduce this? I've tested this with several repositories and bundled projects and have not spotted any issues yet. So far I have to assume this is a local problem, possibly related to your include path configuration?

[EvanK]

On a fresh trusty32 vagrant machine with apt-installed wget, git and php5-cli, I tested (1) the composer-installed phpunit, (2) the phar I linked to earlier in this issue, and (3) a freshly built phar.

It seems to build and even execute the phars just fine, but it's actually using the locally vendor installed version of phpunit in each case -- note the version numbers:

# using composer-installed phpunit (4.7.5)
~/graph$ ./vendor/bin/phpunit
PHPUnit 4.7.5 by Sebastian Bergmann and contributors.

...............................................................  63 / 161 ( 39%)
............................................................... 126 / 161 ( 78%)
...................................

Time: 162 ms, Memory: 4.50Mb

OK (161 tests, 406 assertions)

# using pre-built phpunit phar from dropbox (4.6.2)
~/graph$ sudo wget -O /usr/bin/phpunit https://dl.dropboxusercontent.com/u/56187/phpunit.phar?dl=1
~/graph$ sudo chmod +x /usr/bin/phpunit
~/graph$ /usr/bin/phpunit
PHPUnit 4.7.5 by Sebastian Bergmann and contributors.

...............................................................  63 / 161 ( 39%)
............................................................... 126 / 161 ( 78%)
...................................

Time: 203 ms, Memory: 5.00Mb

OK (161 tests, 406 assertions)

# building new phpunit phar (4.6.8)
~/graph$ ~/phar-composer/bin/phar-composer build phpunit/phpunit:4.6.8
~/graph$ chmod +x ~/phar-composer/phpunit.phar
~/graph$ ~/phar-composer/phpunit.phar
PHPUnit 4.7.5 by Sebastian Bergmann and contributors.

...............................................................  63 / 161 ( 39%)
............................................................... 126 / 161 ( 78%)
...................................

Time: 177 ms, Memory: 5.00Mb

OK (161 tests, 406 assertions)

[clue]

It seems to build and even execute the phars just fine, but it's actually using the locally vendor installed version of phpunit in each case -- note the version numbers:

I can reproduce this locally. Afaict I suppose this is not a bug – it's a feature 😋

~/graph$ ./vendor/bin/phpunit --version
PHPUnit 4.5.0 by Sebastian Bergmann and contributors.

~/graph$ phpunit --version
PHPUnit 4.8.14 by Sebastian Bergmann and contributors.

~/graph$ phpunit
PHPUnit 4.5.0 by Sebastian Bergmann and contributors.
[…]

I suppose phpunit explicitly checks the vendor-installed version if available in order to produce consistent results for projects having a dependency on a given version?

I'll close this as a resolved question, unless we can reproduce this for other projects as well. Thanks everybody for reproducing this!