/bin/child-process has absolute path to vendor/autoload.php breaking relocation of source

[lucasnetau]

The new /bin/child-process file that is generated in v4.0 breaks deployments when mapping to seperate location due to hard-code absolute path to vendor/autoload.php

In development we install composer dependencies on the development machine and then this directory is mapped through to Docker containers through volume mapping. The absolute path to autoload.php in the Docker container is not the same as the absolute path on the development machine (different OS). This causes a Fatal error running our ReactPHP components

What is the purpose of hard-coding the path to autoload.php in a library?

[WyriHaximus]

The assumption, when adding that enhancement to this package, is that source isn't moved around. The thing I didn't consider at the time was volume mapping in Docker containers and the likes. The whole purpose of putting it in there hardcoded (using a composer plugin) is to be 100% sure where to expect the autoloader to be. And not have to guess by iterating over a set of possibilities each time it's started.

However that should not cause issues for you, it was done, rather lazy, with the absolute path of the autoloader as supplied by composer. I'll look at using a relative path instead, that will still ensure the same functionality, but shouldn't cause issues in your use case.

[WyriHaximus]

PR with a fix is up at WyriHaximus/php-composer-update-bin-autoload-path#36

[lucasnetau]

Will the PR with the fix be merged anytime soon?

[WyriHaximus]

In its current state not. In theory, it should work fine, in practice however it doesn't. So, when I faced that issue I went back to the drawing board and got distracted by another drawing board. But there might be a simpler solution I'm going to try later this week and than hopefully we can resolve this.

[WyriHaximus]

@lucasnetau Can you try this for me? Instead of fixing it upstream, I've added a fallback in case the absolute path doesn't work:

composer require wyrihaximus/react-child-process-messenger:"dev-4.x-fallback-autoloader-paths as 4.1.0"

(Have to fix it in this package in the short term, but will fix it in https://github.com/WyriHaximus/php-composer-update-bin-autoload-path to do that out of the box.)

[lucasnetau]

Patch did not work, it's trying to load a find vendor.php under the wyrihaximus path, there is no vendor.php under /vendor in any directory.

PHP Warning:  require_once(/ie/vendor/wyrihaximus/vendor/vendor.php): Failed to open stream: No such file or directory in /ie/vendor/wyrihaximus/react-child-process-messenger/bin/child-process on line 14
PHP Fatal error:  Uncaught Error: Failed opening required '/ie/vendor/wyrihaximus/vendor/vendor.php' (include_path='.:/usr/local/lib/php') in /ie/vendor/wyrihaximus/react-child-process-messenger/bin/child-process:14
Stack trace:
#0 /ie/vendor/wyrihaximus/react-child-process-messenger/bin/child-process(15): {closure}()
#1 {main}
  thrown in /ie/vendor/wyrihaximus/react-child-process-messenger/bin/child-process on line 14

What exactly is the reason for the $binPathAutoloader and $vendorPathAutoloader guessing? What install case cause autoload.php not to be resolved at

dirname(__DIR__, 3) . DIRECTORY_SEPARATOR . 'autoload.php';

[WyriHaximus]

Ow, yeah doh my bad. Just pushed an update.

The use case are packages like this one that comes with a bin. Composer doesn't put the bin of such package when you're developing on the package in vendor/bin as it does with dependencies. Hence creating a package to make it absolute, but that didn't consider for your edge case, hence having to fall back to guess.

[lucasnetau]

No problems, I tested it an it is working for me.

Have you had a look at what some other libraries do? nesbot/carbon defines their binary in composer.json "bin": [ "bin/carbon" ] so that it is symlinked into vendor/bin and then checks three different paths for the autoload.php, symfony/var-dumper does similarly.

[WyriHaximus]

No problems, I tested it an it is working for me.

Cool, will be releasing it later today/tomorrow then.

Have you had a look at what some other libraries do? nesbot/carbon defines their binary in composer.json "bin": [ "bin/carbon" ] so that it is symlinked into vendor/bin and then checks three different paths for the autoload.php, symfony/var-dumper does similarly.

Thought I had it in there as well. So that's a bit weird, but I'll have a test with it soon because that would have been my expectation as well.

[voku]

I don't know if it's the same problem, but I see this error message: Could not open input file: phar:///home/lmoelleken/meerx/Framework/thirdparty/phpdoctor.phar/vendor/wyrihaximus/react-child-process-messenger/bin/child-process when I try to use react/filesystem in a phar file. Any idea how I can fix that on my end?