if used with php, why not set launch=true? about httpd

[dmikusa]

Here's an integration test that weaves them together -> https://github.com/cloudfoundry/php-web-cnb/blob/master/integration/deploy_a_php_app_with_all_modules_test.go#L118

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/166283710

The labels on this github issue will be updated when the story is started.

[dmikusa]

I apologise if this is a silly question - I'm desperately trying to figure out how to combine php/httpd buildpacks to run a php app.

This is still in flux and a lot of these cnb's are still changing (and all need to be better documented), but hopefully, this graphic will explain a bit for now. It's pretty much up-to-date.

Biggest note is that I don't believe we have an Nginx buildpack at this time. The idea is it would function like HTTPD and be interchangeable.

[drnic]

Is there an implementation reason for splitting php-cnb and php-web-cnb into two CNBs; or is it exploratory/idealistic to breaking functionality into as many small CNBs as passible?

Could php-cnb have also implemented the optional behavior of php-web-cnb? Or can buildpacks only be "supply" (php-cnb) or have runtime features? (php-web-cnb)?

[dmikusa]

Is there an implementation reason for splitting php-cnb and php-web-cnb into two CNBs; or is it exploratory/idealistic to breaking functionality into as many small CNBs as passible?

My understanding is that the idea is to split things up so that they can be more composable. Having a buildpack that just delivers PHP, makes it composable in that you can substitute what provides PHP easily (changing compositions is as easy as creating a builder, pack create-builder). Want to use HHVM? Just add a CNB that supplies it and it should work well with the rest of the buildpack. Similarly, you could decide to use a PHP buildpack that provides binaries from some other source like Ubuntu's official package repo, or something like that. As long as PHP's there, it should work with the other buildpacks. The web servers are broken out in a similar way, so that it's easy to pick the one you want.

That's in theory at least. Right now I'm sure there are some little things you'd have to work out to get the contract just right and that's not documented/could change. Over time I hope it will solidify though and you can compose your own PHP stack by combining the different CNBs.

Could php-cnb have also implemented the optional behavior of php-web-cnb? Or can buildpacks only be "supply" (php-cnb) or have runtime features? (php-web-cnb)?

I think you could have put everything into one buildpack like with v2. There's nothing to restrict that. It's just going to be a more complicated buildpack. Splitting them out makes them simpler and more focused and easier to test. Plus the benefits I mentioned about being able to compose them.

Once you start splitting things out, the order of how you run them becomes very important to get right. PHP has to come first because things like Composer need it to be there to run. At the same time, you don't know what version of PHP to install until you look at your Composer files to see what the user wants. If you want Composer in its own CNB, then that gets tricky. There are similar issues with the web server CNBs. Making a php-web CNB allowed us to defer a lot of the logic for what to install and how to configure it to the end of the detect & build cycles. That allowed us to have all the information to make decisions but also split out into multiple CNBs.

[drnic]

Thanks for explaining that.