Cannot reproduce the CI error locally:./phpunit install ->Cannot open file "install.php".

Any hint? /cc@nicolas-grekas

Thats' a pretty big change. Shouldn't we consider it as a new feature?
Note that we should use anonymous functions instead of global ones as we shouldn't pollute the global function space.

@nicolas-grekas did change it to anonymous functions. from my case we can consider it as a new feature, but not sure what to add/change at the documentation because think most people think that the phpunit config variables would also be used in parallel test runs?

Could now reproduce and fix the travis ci bug locally by changing the./phpunit file using the new simple-phpunit binary:

diff --git a/phpunit b/phpunitindex f4b80ed064..e88c75c331 100755--- a/phpunit+++ b/phpunit@@ -11,4 +11,5 @@ if (\PHP_VERSION_ID >= 70000 && !getenv('SYMFONY_PHPUNIT_VERSION')) {     putenv('SYMFONY_PHPUNIT_VERSION=6.5'); } putenv('SYMFONY_PHPUNIT_DIR='.__DIR__.'/.phpunit');-require __DIR__.'/vendor/symfony/phpunit-bridge/bin/simple-phpunit';+require __DIR__.'/src/Symfony/Bridge/PhpUnit/bin/simple-phpunit';

Should we maybe use always the simple-phpunit from repository not from vendor to avoid this kind of problems for contributors?

But can't reproduce the current error its really hard to understand what the travis script does, would be better as a php script that you can run it also locally on all operation systems.

Should we maybe use always the simple-phpunit from repository not from vendor to avoid this kind of problems for contributors?

nope, the reason being that we want to use the latest version of the bridge to test the lowest maintained Symfony versions (2.8 for now, so PHP 5.3.3 should still be supported).
At the end of November, 2.8 will be released so that we'll be able to bump the minimum PHP version of the bridge to PHP 5.5.9.

@nicolas-grekas Using anonymous functions like that and globalizing their containers (variables) like this, I wonder if using the global function scope wouldn't be better... Or maybe adding a namespace in the simple-phpunit file, to restrict these functions in said namespace could be better ?

@nicolas-grekas any news to this?

Please rebase.

@nicolas-grekas done.

@nicolas-grekas I think we're waiting for you here :)

@nicolas-grekas if you have time we could have also a look at this at theEU-FOSSA Hackathon

Sure, please rebase meanwhile ;)

@nicolas-grekas Rebase done ;)

I feel like the expectations implemented by this PR are wrong, here is why:
running this with the originalphpunit doesn't read thephpunit.xml.dist in the subdirectories.

Try running e.g.phpunit src/Symfony/Bundle/FrameworkBundle/ - this doesn't readsrc/Symfony/Bundle/FrameworkBundle/phpunit.xml.dist - thus doesn't read itsbootstrap.php

Running./phpunit src/Symfony/Bundle/FrameworkBundle/ should produce the same result.

@nicolas-grekas didn't know that the original phpunit allows to give a folder 🙈 thought that was a symfony only feature. Yeah it definitly make sense that the result then is the same as using the original phpunit file.

Closing as discussed, thanks.