feat: embed PHP thanks to FrankenPHP

[dunglas]

Thanks to FrankenPHP, it's possible to embed PHP directly in the Symfony Local Web Server.
That's what this patch does!

symfony server:start --frankenphp

Basically, that means that you don't need a local installation of PHP anymore.

The code is working, but the build chain isn't ready. We'll have to build libphp in the CI and statically link the produced binary against it.

Support for other PHP SAPI is still included and FrankenPHP is currently opt-in.

Current limitations are:

• PHP 8.2 is currently supported (theoretically, we could link dynamically against various PHP versions)
• PHP extensions need to be installed separately (but work)
• PHP CLI isn't supported yet: feat: add CLI support php/frankenphp#4
• Windows support is a WIP: Windows compatibility php/frankenphp#83

Needs symfony-cli/phpstore#3

[shyim]

Does it make sense to have here a go build tag? Frankenphp uses a lot of cgo which would break the release ci pipeline as it's not possible to cross compile anymore 🤔

[dunglas]

We could do that, but first I'll try to have to build a release pipeline supporting all current targets (they are supported by PHP, and we can use Docker to cross-compile).

[Kocal]

That's a great initiative, but would it support the .php-version feature?

[dunglas]

@Kocal not yet. FrankenPHP is only compatible with PHP 8.2+.

[kevinpapst]

How much will that increase the size of the Symfony binary? Why does one tool have to solve all issues?

[stof]

As we still need to have a local PHP setup for the CLI (a Symfony project requires a PHP CLI, at least to run composer), is there any benefit for that ? This only saves installing the php-fpm package locally in addition to all the other packages that are shared with the php-cli one.

[tucksaun]

How much will that increase the size of the Symfony binary ?

I would say about 100mb (rough estimate)

As we still need to have a local PHP setup for the CLI (a Symfony project requires a PHP CLI, at least to run composer), is there any benefit for that ? This only saves installing the php-fpm package locally in addition to all the other packages that are shared with the php-cli one.

I agree.

Also we lose the multi version support and we don't expose the configurability of Franken so no big win here I think.

[tucksaun]

Maybe we can do something by working wi Go plugins to have this optional?
or reuse the fact we can talk HTTP or CGI with the backend server?

[dunglas]

@stof, FrankenPHP now natively supports CLI scripts too. The Caddy plugin already has this feature, this should be easy to add to Symfony CLI.

[dunglas]

Also, FrankenPHP supports libphp.so in addition to static builds, so it should be possible to distribute (or , better, download on demand) different PHP versions, for instance from the PHP Builder project (also used by setup-php), which provides dynamic libphp builds compatible with FrankenPHP. This approach would also have the benefit of not increasing much the binary size.

[tibobaldwin]

Hi,
Is this feature still current?
Should we rather go directly through the FrankenPHP website?
In any case, it is true that this will facilitate the integration of FrankenPHP by going through Symfony CLI.
Thank you!

[dunglas]

In my opinion, the best option would be to do in the other way: extract the Symfony-specific features provided by symfony-cli in a standalone Go library and provide it as a plugin for FrankenPHP.

cc @fabpot @tucksaun

[tucksaun]

I'm not sure this would add much value doing it this way (because if I picture it correctly most features would not make sense in a Franken context or be a duplicate of Franken's).
But because there's almost nothing in main for the Symfony CLI, I believe one could already do that if they want to invest the effort to do so.