PHP-Warning due to redundant stream_wrapper_register-calls in php-proxy-binaries, when using chained inclusions

[brandung-sjorek]

Hello,

I have two independently installed projects, let's say vendor-a/foo-project and vendor-b/bar-project. Both projects are located in directories which do not intersect and both projects have a composer-generated php-proxy-binary installed in their {$bin-dir} (vendor/bin). The binary from a-vendor/foo-project shall include(…); the binary from vendor-b/bar-project. (This is weird and it looks a bit esoteric, at least at the first glance. I know this, but I have reasons. 😞) Nevertheless, this strategy combined with the lately introduced phpvfscomposer stream-wrapper, which was embedded in these proxy-binaries to avoid problems with the shebang of included php-scripts for PHP < 8, results in warnings for composer version ≥ 2.2 in combination with PHP version < 8.

The composer.json from vendor-a/foo-project:

{
    …
   "type": "library",
   "bin": [
        "foo"
    ],
    …
}

The composer.json from vendor-b/bar-project:

{
    …
   "type": "library",
   "bin": [
        "bar"
    ],
    …
}

Output of composer diagnose:

Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 2.3.6
PHP version: 7.4.29
PHP binary path: /opt/local/bin/php74
OpenSSL version: OpenSSL 1.1.1n  15 Mar 2022
cURL version: 7.83.1 libz 1.2.12 ssl OpenSSL/3.0.3
zip: extension present, unzip present, 7-Zip not available

So, when I run this command and if php-proxy-binary vendor/bin/foo includes another php-proxy-binary vendor/bin/bar:

❯ ./vendor/bin/foo

I get the following output:

PHP Warning:  stream_wrapper_register(): Protocol phpvfscomposer:// is already defined. in /…/vendor/bin/foo on line 110
PHP Stack trace:
PHP   1. {main}() /…/vendor/bin/foo:0
PHP   2. include() /…/vendor/bin/foo:112
PHP   3. stream_wrapper_register($protocol = 'phpvfscomposer', $classname = 'Composer\\BinProxyWrapper') /…/vendor/bin/bar:110

This warning is caused by …

#!/usr/bin/env php
<?php
…
    if (function_exists('stream_wrapper_register') && stream_wrapper_register('phpvfscomposer', 'Composer\BinProxyWrapper')) {
        include("phpvfscomposer://" . __DIR__ . '/..'.'/vendor-b/bar-project/bar');
        exit(0);
    }
…

… because there ist no “stream-wrapper is already registered” check or a stream-wrapper unregistration implemented for this case.

And I expected this to happen:

… well, I expect that this warning does not happen. 😄

I thought about this, and came up with three possible solutions:

• a) unregistering the phpvfscomposer stream-wrapper as early as possible, for example in its constructor, so right after it has been instantiated
  • PR: allow chained proxy-binary php-inclusions - solution (a) #10821
• b) unregistering any existing phpvfscomposer stream-wrapper before registering the stream-wrapper
  • PR: allow chained proxy-binary php-inclusions - solution (b) #10822
• c) skip the registration of phpvfscomposer stream-wrapper, if stream-wrapper with the same name ist already registered
  • PR: allow chained proxy-binary php-inclusions - solution (c) #10823

What do you think? I would prefer solution (a), because it does not leave any traces of the stream-wrapper behind.

Thanks for your patience so far,
and I appreciate any feedback!

Stephan

BTW.: The whole composer-community has done a great job!

[Seldaek]

Thanks for the detailed report.

I agree (a) sounds good, but we did try that initially and it did not work - had to be reverted in 09d1330

Thus I think solution (c) is the best option, as it fixes the only problem which is double registration. As the class can only be defined once anyway unregistering/re-registering it wouldn't make any difference.

[Seldaek]

Fix is in 2.3.7 / 2.2.14

[brandung-sjorek]

Would be interesting to know, why unregistering did not work in 09d1330 … as it works for me for PHP version 7.0 up to version 7.4 (and also for 8.0 to 8.2). Must have been a PHP version ≤ 5.6 or a broken 7.x release.

Nevertheless, thanks a lot!

[Seldaek]

The unregistering was working, but some tools inspecting stack traces then crapped out when checking files that contained the stream wrapper, see #10387 (comment) for example.