[RFC] Single binary for CLI and FPM

14 hours ago by Marc Henderkes — view source — reply

unread

Hi

Right, good point, I agree too, thanks!

I opened a new PR that goes the other way around:
https://github.com/php/php-src/pull/24192

I have also updated the RFC:
https://wiki.php.net/rfc/single-binary-cli-fpm

php CLI is unchanged

php-fpm always includes php (and runs as CLI when run as php
instead of php-fpm)

no need for a build option anymore

the diff is simpler

FPM aligns with FrankenPHP (both include the CLI)

No --fpm CLI option anymore, solves the objections raised
previously in this thread

That sounds much better indeed.

I disagree that this is better from a discoverability and predictability
point of view and I also disagree with the concerns that the original
proposal would somehow “privilege” FPM.

As for the first part:

When running a PHP binary on the command line, my expectation is that
I'm running a CLI application and thus I expect to end up in the CLI
SAPI. Suddenly starting FPM, which potentially binds ports or sockets,
just because I happen to name the binary the wrong name (e.g. when using
a custom p symlink to run PHP after my distro switched to the
“combined binary” setup or just php-8.7 that the RFC notes as running
FPM) would be very surprising. With the current proposal I also have no
way out, except naming the binary differently. Changing behavior based
on the binary name to do entirely different things is something that is
comparatively rarely used and thus folks are unlikely to be accustomed
to this being a thing (the most prominent example that comes to mind
would be Busybox). An explicit flag / argument would be properly
discoverable (appearing in help outputs) and would also be reliably
scriptable.

For the second point, and tying into the first: PHP FPM is a / the
recommended solution of running PHP as a FastCGI application. Adding an
--fpm flag to the PHP binary to run PHP in “FastCGI mode” would match
the -S flag to run PHP in “HTTP mode” (which switches from the cli
to the cli-server SAPI). I understand that the current “HTTP mode”
implementation is meant to be used for development purposes only, but
that is an implementation detail. We could in theory implement a
production grade web server to PHP tomorrow (and potentially add
--http as the entrypoint for the “HTTP mode”, keeping -S as an
alias) and then we would have:
 php # CLI mode
 php --fpm # FastCGI mode
 php --http # HTTP mode
with the php binary being the singular entrypoint for all use cases
where PHP is running “standalone” rather than embedded into something
else (as with mod_php). Alternatively, we use --mode=fpm to switch to
FPM mode instead of reserving the top level --fpm flag.

Best regards
Tim Düsterhus

I agree with Tim here, for three reasons:

ergonomically, using php --fpm <fpm-args> is clearer than being forced to rename the binary (I only suggested that it's a possibility for build maintainers)
php-fpm usually lives in /usr/sbin which usually shouldn't be accessed directly by users
even if we ignore that, php-fpm php-cli <cli-args> is silly

I don't share Larry's concern here, I don't see FrankenPHP completely replacing FPM any time soon. There has to remain a way to run php without locking ourselves to Go (and realistically Caddy). But even if it did, dropping a --fpm flag is no different than dropping a php-fpm target.

(Since php --fpm, maybe php --http, or even php --le-monstre ;) are where it would end anyway, so I see no reason to gate it behind a dedicated --mode= flag)

Kind regards
Marc Henderkes