[Scoper] Scoping autoloaded files result in an autoload conflict

[Smitsel]

Edit to avoid to summarise the state of this issue.

When scoping a package which has autoloaded files, the scoped files will keep the same hash. As a result if your current application/library is using the scoped package and has files with the same hash, only one file will be loaded which results in undesirable behaviours.

It appears the hash strategy is not something we can change composer/composer#7942 and changing the package name of the scoped packages has undesirable side effects so it is not a solution either.

@jarrodbell #298 (comment) and @ondrejmirtes #298 (comment) made it work by changing it after the composer dump process as part of the scoping build process.

The discussion is carrying from that point to figure out if there is a way PHP-Scoper could fix it by itself without further actions from the user.

---

Bug report

Question	Answer
Box version	PHP Scoper version 0.11.4 2018-11-13 08:49:16 UTC
PHP version	PHP 7.1.22
Platform with version	Ubuntu 16.04.5 LTS
Github Repo	https://github.com/mollie/mollie-api-php

We are using php-scoper in our client to generate a release for integrators to be used in for example Wordpress. When it is used there, there are often more packages with Guzzle via composer.

When this happens they will get the exception:
Uncaught Error: Call to undefined function GuzzleHttp\choose_handler()

This is because the corresponding guzzlehttp/guzzle/src/functions_include.php is not loaded for the second implementation due to the composer file require hash being the same.

Below there is an example of our package being ran alongside another guzzle package.
This is a var_dump inside the composer_real.php where the functions_include is being required if the file hash is not already loaded.

array(3) {
  ["c964ee0ededf28c96ebd9db5099ef910"]=>
  string(99) "{path_to_site}/vendor/composer/../guzzlehttp/promises/src/functions_include.php"
  ["a0edc8309cc5e1d60e3047b5df6b7052"]=>
  string(95) "{path_to_site}/vendor/composer/../guzzlehttp/psr7/src/functions_include.php"
  ["37a3dc5111fe8f707ab4c132ef1dbc62"]=>
  string(97) "{path_to_site}/vendor/composer/../guzzlehttp/guzzle/src/functions_include.php"
}
array(3) {
  ["c964ee0ededf28c96ebd9db5099ef910"]=>
  string(106) "{path_to_site}/guzzle/vendor/composer/../guzzlehttp/promises/src/functions_include.php"
  ["a0edc8309cc5e1d60e3047b5df6b7052"]=>
  string(102) "{path_to_site}/guzzle/vendor/composer/../guzzlehttp/psr7/src/functions_include.php"
  ["37a3dc5111fe8f707ab4c132ef1dbc62"]=>
  string(104) "{path_to_site}k/guzzle/vendor/composer/../guzzlehttp/guzzle/src/functions_include.php"
}

So this causes only the first implementation it's choose_handler function to be available.

I'm not really sure if this bug should be reported here, but i'm curious to your expert opinion about this. Might it be worth it to also scope the files that outta be required by composer? To avoid some of them not being loaded? As manipulating the hash in above example would fix the problem.

[theofidry]

Hi! Thanks for the report. It's nice to see it being tried on Wordpress :)

I admit I'm a bit confused.

Uncaught Error: Call to undefined function GuzzleHttp\choose_handler()

Since it is not a function from the global namespace, unless explicitly configured otherwise, I would expect this function to be scoped. If it is the case, then it means somewhere a piece of code has not been scoped properly and is still using the old reference (which can be an expected case. Unfortunately due to PHP nature PHP-Scoper won't be able to be perfect and will sometimes need some help via the patchers).

This is because the corresponding guzzlehttp/guzzle/src/functions_include.php is not loaded for the second implementation due to the composer file require hash being the same.

What I would find weird/confusing there is why would it be a problem for the scoped version and not the unscoped one? Also if the hash file is the same it means the content is the same, so indeed there shouldn't be a need to include it twice should it?

[Smitsel]

Yes, it's not a function from the global namespace, but since it is defined in the functions_include.php it will not be available for the second guzzle package.

The hash is the same even though the contents are not.

Scoped functions_include.php:

<?php

namespace _PhpScoper5c3efd0df2edb;

// Don't redefine the functions if included multiple times.
if (!\function_exists('_PhpScoper5c3efd0df2edb\\GuzzleHttp\\uri_template')) {
    require __DIR__ . '/functions.php';
}

Unscoped functions_include.php:

<?php

// Don't redefine the functions if included multiple times.
if (!function_exists('GuzzleHttp\uri_template')) {
    require __DIR__ . '/functions.php';
}

So whatever functions_include.php gets loaded first is the one that will work.
As the second one won't be included.

[theofidry]

The hash is the same even though the contents are not.

Hm this is very weird then. Has the autoloader been dumped again after the scoping?

[Smitsel]

Yes, i've done a lot of testing with it.

I've tried adding even more code to the functions_include.

Does not change a thing, unfortunately.

[theofidry]

I think it would be best to try to narrow down the issue in a reproducible repo to ease the debugging. It may be a bug in Composer or it means Composer is relying on the hash from the installed.json files which would be troublesome and means we would need to do something about it for PHP-Scoper to work properly in this scenario

[Smitsel]

I'll create a repo for you 👍

[Smitsel]

The repository:
https://github.com/Smitsel/guzzle-scoper-reproduction

If you run into any problems or need any more information just let me know :)

[theofidry]

👍 I'll try to take a look ASAP but it's likely gonna take a couple of weeks, this month is quite busy for me :/

[Smitsel]

Not a problem. We can hack in a solution if it becomes really pressing. Happy that you are willing to take a look!

[willemstuursma]

It's probably here:
https://github.com/composer/composer/blob/master/src/Composer/Autoload/AutoloadGenerator.php#L903

[Smitsel]

Yep, manipulating the package name fixes it indeed.

Very weird choice to do it just based on that. They should also compare content-size or something.

[sandervanhooft]

I'd hash the whole package directory file (incl contents), but that may be a bit resource expensive 😄

[theofidry]

it's for the dumping the autoloader so I don't think it would be a big deal

[sandervanhooft]

Would using getDistSha1Checksum() be a solution? It's on the PackageInterface.