-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/bin/child-process has absolute path to vendor/autoload.php breaking relocation of source #72
/bin/child-process has absolute path to vendor/autoload.php breaking relocation of source #72
Comments
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. |
When this package was initially designed it didn't take into account situations where files aren't moved. But are mounted into a running Docker container for development. By switching to relative paths both situations, and most logical others are supported. Resolves: WyriHaximus/reactphp-child-process-messenger#72 (reported by @ lucasnetau)
When this package was initially designed it didn't take into account situations where files aren't moved. But are mounted into a running Docker container for development. By switching to relative paths both situations, and most logical others are supported. Resolves: WyriHaximus/reactphp-child-process-messenger#72 (reported by @lucasnetau)
PR with a fix is up at WyriHaximus/php-composer-update-bin-autoload-path#36 |
When this package was initially designed it didn't take into account situations where files aren't moved. But are mounted into a running Docker container for development. By switching to relative paths both situations, and most logical others are supported. Resolves: WyriHaximus/reactphp-child-process-messenger#72 (reported by @lucasnetau)
Will the PR with the fix be merged anytime soon? |
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. |
@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.) |
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.
What exactly is the reason for the $binPathAutoloader and $vendorPathAutoloader guessing? What install case cause autoload.php not to be resolved at
|
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 |
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 |
Cool, will be releasing it later today/tomorrow then.
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. |
I don't know if it's the same problem, but I see this error message: |
@voku Even with the latest version? IIRC I did release that change. Will have a look tonight and get back to you. |
I tested this version: composer.lock: 4.x-dev ⇒ "7aebab12f12a09f80a36ce6f5d34a4832a5b6fa5" EDIT: Now I tested "dev-master ⇉ "04369f7894b88c7e4c7883571c77e308a9510e05" (via
|
@voku That's a incompatibility known incompatibility. Ok right I'm pretty sure I found it, and feel so stupid now 😂 . Please have a go with |
This is still not working, same error message. Maybe I can fix that on my end, by some configuration for box, php-scoper, ...? |
@voku This error? If so, then the autoloading works, but we have another issue on our hands.
|
Sorry, no it's still this error |
Honestly? No clue, never build this with phar in mind. Will look into this during the holidays. |
Later than I hoped, but I just started looking into this. And from what I gather now the only way is to ship this package with a Phar that can be read from your Phar, put on the host filesystem, and be executed. Deep under the hood of |
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?
The text was updated successfully, but these errors were encountered: