[throwmeout123]

You almost convinced me to try it again but then i remember about:

* php.ini * php extensions * hardish deploy needing a specially configured web server * huge number of terribly named builtins * functions returning int|bool|null|whoknows * $, -> * cant trivially dockerize * laravel wants me to install even more crap other than Apache phpfpm php composer artisan sail larathis larathat so he can buy the second lambo by copying rails and django * xdebug

And i just go on my merry way. Php devs forgot the mountain of quirk and bullshit they internalized. That’s the same reason I’m starting to hate python

[mwint]

Can you add some color the bit about it not being trivially dockerized? Might be doing this soonish for work, would love extra info.

[throwmeout123]

For a Production setup we had to configure an nginx container plus the FPM container, let em talk, Configure some more Commands to enable/disable xdebug (that requires a restart of the containers since it needs a php estension) and i think that’s all. Other langs we use are literally “run the app” then kube will handle the rest.

[husarcik]

I skip all of that and use a docker image with octane. Much faster and easier to maintain. No separate FPM container too!

[husarcik]

I skip all of that and use a docker image with swoole. Much faster and easier to maintain. No separate FPM container too!

[kyriakos]

Why would you enable xdebug in production?

[throwmeout123]

I wouldnt but the container setup was the same to prod

[mwint]

Got it, thanks!

[throwmeout123]

Yw, not really hard but since we’re not a php shop it required a lot of research, trial and error, complexity as in “need to know something not related to Application or domain” and ops are unhappy at having to support this one of a kind setup. There might be a better way tho