make standard PHP frameworks work (drupal, laravel, symfony) #46
Comments
|
I might be testing this against the wrong version — I see |
|
Ok, I ran the following for Laravel (to get the latest updates from here): Also had to add a few extensions, but that's kinda expected. I'll test the others. |
|
For completeness, here are the necessary extensions for laravel (that I added to
|
|
I briefly tried Drupal, but the setup is too involved right now as it requires database, etc. and I lack time. I then tried a symfony app, to contain it a little, I used their API skeleton: And used the following [ build ]
[[ build.env ]]
name="BP_PHP_SERVER"
value="httpd"
[[ build.env ]]
name="BP_PHP_ENABLE_HTTPS_REDIRECT"
value="false"
[[ build.env ]]
name="BP_PHP_WEB_DIR"
value="public"
[[ build.env ]]
name="BP_COMPOSER_INSTALL_OPTIONS"
value="--no-scripts -o"Then run, Start the app like so: Produces the following exceptions once I access a route: As you can see, while my app code is in I think they should be in I disabled the use of {
"extra": {
"runtime": {
"disable_dotenv": true
},
}
}And then the application works. Using or not using |
|
Hey Till! Thanks for the details, and for trying out a different types of apps. I'm glad that including #25 solved the Laravel issue, but it's helpful to know that the other cases still have some hiccups. It seems like the implementation I put in to solve that issue was incomplete, and doesn't cover all of the cases for different directories that might be needed. I think you're completely on the right track. With the examples you've given we should be able to pin down how the symlinking behaviour should work without having to make tons of changes to the apps, but hopefully we can retain the ability to reuse the layer on rebuilds. As a PHP maintainer I'd definitely like to see this issue prioritized so we can have a better user experience for real use cases, @paketo-buildpacks/php-maintainers what do you think |
|
I looked into the weird dotenv errors, and the symlinking. Not sure how to guard against that:
You can override this behaviour via But I guess it goes to show that somehow, I would like the dependencies to end up in |
|
Our implementation should definitely try to follow the most common use-case standards, so it's worthwhile to fix this. |
|
I did a debugging session with one of the composer folks yesterday. So for Symfony, I think this is the TL;DR:
I am guessing in order to make this work, I either implement my own buildpack or somehow convince you that this needs changing. The current layers don't work for this. Any idea how to move this forward? |
|
Composer folks as in, someone who works on composer? That's awesome!! I think we are aligned that this is a valuable use case to support in the Paketo buildpacks in order to make the buildpacks actually useful for PHP developers. I am definitely interested in looking into this, it's more of a question of finding time to investigate this within the core team. I'll see about that. If time is of the essence, we're obviously happy to accept a contribution (I realize this issue requires a lot of buildpack knowledge though). More likely, when we're able to get to this, perhaps we can confer with you as a reviewer to understand if we are doing the right thing. |
|
@fg-j made the suggestion that Slice Layers could work well for this situation. If, for example, |
|
@thitch97 @sophiewigmore Is there anything I can do to move this along? We are currently debating options as to how to move forward. We have a few people on our end waiting for a solution. |
|
@till we currently have this prioritized as something we will work on in the near future, but it is sitting below a few other things we need to get done first, like finishing rolling out Jammy stack support. I'd estimate it'll be a few weeks before we can get to it. You've already given us a lot of help with how to create sample apps to test against, but beyond that, you are welcome to contribute any way you see fit. (Assuming CLA woes are resolved?) If you are interested in contributing, I'm happy to add more context about that. |
|
(Oops, didn't mean to close the issue 😅 ) |
Yes, definitely interested to contribute once I understand scope. |
|
Right, you've already created some simple sample apps for each framework, which would be helpful to add as sample apps that we can then add some to failing integration tests for. This would be a really great starting place. For context, the integration tests work by performing real builds of the apps with the buildpack, and running the final app image. We run them locally using After adding tests for each of the frameworks, I think it would be helpful to nail down exactly what about each framework app is failing. I think we have a lot of that information spread out in the various issues already. Specifically, can we enumerate all of the potential paths that we'll need to include in a layer? Once we're at this point it's going to be figuring out the best way to rework the buildpack either using the layer slicing suggestion above, or in another way. |
|
@till I have opened #92 to try to fix symlinking issues. Hopefully this will resolve the main bug we're seeing with all framework apps. More work will need to be done on other buildpacks to resolve the issue you have with the amount of configuration needed I'd like to also follow up and say thank you for the context you shared, and the examples of how you gave here of how to set up apps, and configuration you provided. It made my experience much easier working on this. |
|
this fix is available in https://github.com/paketo-buildpacks/composer-install/releases/tag/v0.2.1 |
|
@till if you get a chance to test out the changes, please let us know if this has resolved this issue by closing this issue out! |
|
@sophiewigmore Is this already part of a release of the php buildpack? |
|
@till I am working on a release of the PHP buildpack right now |
|
@till any update here or shall I close this out? |
|
@sophiewigmore give me a day. Latest by Monday. To test. Sorry for the delay. 😐 |
|
No worries! It's not urgent. |
|
@sophiewigmore it's a pity that this fix is only available for php8, is it possible to extend it to php7.4 as well? |
|
Hey @owlfog, the reason that this doesn't work for PHP 7.4 is because we removed support for PHP 7.4 from the buildpacks all together in December, because it has gone EOL upstream |
|
It's been a bit so I'm going to close this out so we can stop tracking it. Feel free to reopen it if this problem comes back or is not satisfied by our fix |
|
Hi. I'm one of the maintainers of Drupal. Even though this issue is closed, I thought it might help to post this comment here anyway. I took the Paketo buildpack for a spin with installing Drupal, and overall I'm very happy and impressed with what the Paketo community has done. Thank you for creating a well thought out and implemented system for creating container images of PHP (and other language) apps. Even if the Paketo buildpack worked perfectly, I would still expect to need some Drupal-specific scaffolding, for things like creating a group-writable directory for CMS file uploads, for setting up a database connection (which could be as simple as a SQLite file), and for sourcing Drupal-required settings from environment variables (which isn't the default for non-containerized Drupal, but is the idiomatic approach for containers). Drupal already comes with a Composer plugin for installing scaffold files, so I created https://github.com/effulgentsia/drupal-paketo-scaffold, which is just 4 files in the scaffold directory and a composer.json file that specifies where each of those 4 files needs to be installed. A Drupal app simply needs to The only Paketo-related stumbling blocks that I ran into while building the above were:
Per above, none of them showstoppers, so again, thank you! |
|
Hey @effulgentsia, welcome! 👋 I haven't had a chance to really dig into the issues you've provided, but they're valuable context for us to use as a starting place to improve the user experience. I look forward to collaborating with you on these issues!! |
This is a follow-up to:
paketo-buildpacks/php#253
paketo-buildpacks/php#284
paketo-buildpacks/php#366
(Was asked by @sophiewigmore to move it here.)
Expected Behavior
Setting up a demo app through
oneall of the frameworks, should produce a runnable application.Current Behavior
After providing configuration such as the following:
... an image is produced, but the applications fail with all kinds of errors about being unable to load classes:
Possible Solution
I haven't figured this out completely yet, but it seems like the composer autoload is broken. And all frameworks rely on that to be there. I am only guessing, but maybe due to how the layers work. I've explained in the other ticket how autoloading works, and why.
A possible solution is to squash the layers, I think it's related tot his:
But not yet sure how to debug this or change this to verify my assumption.
Another thing I would try is, if I can
composer dump-autoloadbefore the httpd starts. But I haven't found a hook yet. Maybe someone else has an idea.Steps to Reproduce
You need to have composer installed and set up a project, using laravel as an example:
Run pack with full builder, etc..
Log output 👇🏼 , the
packrun is successful. But then the app doesn't run.Motivations
Trying to make demo apps run, without editing
composer.jsonand other hacks. I think that if we can figure out how to make these three frameworks run,allalmost any project using composer should work.The text was updated successfully, but these errors were encountered: