Phar file not executable from vendor/bin

[Wulfheart]

When the phpunit.phar is distributed via composer in the vendor/bin folder then no output is shown.

I would prefer to use it that way in my projects as it then has the benefit that I don't have many dev dependencies I would only need for phpunit and I have the benefit of not having to download the phar each time.

In the issue composer/composer#11555 the problem got narrowed down to the following snippet:

phpunit/build/templates/binary-phar-autoload.php.in

Lines 58 to 62 in 15a89f1

	if (__FILE__ === realpath($_SERVER['SCRIPT_NAME'])) {
	$execute = true;
	} else {
	$execute = false;
	}

After looking into it I saw that it was related to some bugs in the process isolation.

Related issues I found:

• Running phpunit-7.4.0.phar with phpdbg throws NOTICE #3352
• Process Isolation does not work when using PHPUnit from PHAR #2467 (especially Process Isolation does not work when using PHPUnit from PHAR #2467 (comment))

As far as I understand v10 was a major rewrite. Is it now possible to support the distribution via a bin directory?

[sebastianbergmann]

When the phpunit.phar is distributed via composer in the vendor/bin folder then no output is shown.

We do not distribute PHPUnit's PHAR via Composer, so I am not sure I understand what you are trying to report.

PHPUnit's PHAR should not care about where it is located. I am not able to reproduce a problem when it is located in vendor/bin/phpunit:

$ ls -lh vendor/bin/phpunit 
-rwxr-xr-x. 1 sb sb 4.5M Jul 17 14:10 vendor/bin/phpunit

$ ./vendor/bin/phpunit --version
PHPUnit 10.2.6 by Sebastian Bergmann and contributors.

[Wulfheart]

Thanks for your response.
I wanted to distribute the phar as part of a "quality tools"-package. For reproduction purposes you can use this package with composer require --dev wulfheart/phpunit-shim. If you execute vendor/bin/phpunit.phar then no output will be shown. However, if you execute vendor/wulfheart/phpunit-shim/phpunit.phar then it works fine.

[sebastianbergmann]

Can this issue be closed now that composer/composer#11562 has been implemented?

[ghostwriter]

I was able to get around this issue by executing the Phar directly vendor/ghostwriter/coding-standard/tools/phpunit instead of vendor/bin/phpunit (linked via Composer less thanv2.6 [currently unreleased])

References: https://github.com/ghostwriter/coding-standard/blob/main/composer.json#L36-L47

[Wulfheart]

That’s also my current hack/workaround.

[fredden]

Composer version 2.6.0 has now been released, which includes the fix from composer/composer#11562. I think this issue can now be safely closed.

[ghostwriter]

Thanks for the update and providing the fix. @fredden

[Seldaek]

Sorry @sebastianbergmann but it seems like our fix in Composer caused further issues (composer/composer#11615) as the file still shows up in the backtraces but the last entry in the backtrace doesn't match $_SERVER['SCRIPT_NAME'] I imagine that's the root cause of the issue anyway.. So I'm wondering if we should revert or if this can be fixed in PHPUnit or what to do..

[sebastianbergmann]

I might consider a pull request, but I will not look into this issue myself as installing PHPUnit's PHAR via Composer is not a supported installation method.

[Seldaek]

Ok I see.. my bad for trying to make things play nicer together I guess :D Happy to just revert, but I am curious to fully understand the problem first.