Add --enable-soap

[md5]

I was trying to use the php base image with some code that required SoapClient. Adding --enable-soap to the builds makes this functionality available (cf. http://php.net/manual/en/soap.installation.php).

[md5]

Just rebased this to merge cleanly with the latest master.

[tianon]

LGTM

[daghack]

LGTM

[tianon]

It seems amusing to me that this and FPM are --enable- but so many other things are --with-. It's classic PHP.

So, I'd just mirror here your comment on #34 to advocate for the devil:

Do you think this needs to be enabled by default or would it be fine to have to add an extension=... to the php.ini file?

Is that even possible to do with things like the SOAP support?

The way I see it, if we're going to be using the hard drive space to have the modules built, why not have them enabled by default and have them be opt-out instead?

Also, in the context of #8, I'm still really interested in any way we could have the modules be compiled per use-case (even if it means not deleting /usr/src/php) without having to recompile all of PHP each time.

[md5]

I don't think that the --enable-* flags allow the shared option, but I could research that if you like.

I'd also be interested in a way to compile modules without updating the base image, but I don't have the knowledge or experience to know whether that's possible.

Also, I'll just point out that I literally ran into an app that needs mbstring.so two minutes ago, so I may be sending in a PR to build mbstring.so as a shared extension for #34.

[tianon]

Fair enough! No need to research, I don't doubt it. That's likely the distinction between --enable-* and --with-*.

[tianon]

For reference: http://php.net/manual/en/configure.about.php

[thaJeztah]

The way I see it, if we're going to be using the hard drive space to have the modules built, why not have them enabled by default and have them be opt-out instead?

@tianon The big downside of this is that (when using mod_php / pre-fork) all those extensions will be loaded in memory for each child process that Apache creates. A quick google search for an example; https://www.quantable.com/architecture/mod_php-apache-memory-usage/

So, in short, only enabling extensions that you will actually use can make a big difference on performance and memory footprint. So using shared extensions, which are disabled by default (but easy to enable) might be a better approach.

[tianon]

That sounds fair.

[thaJeztah]

@tianon while writing that comment, I came up with an idea to add extensions "the docker way";

I haven't tested this yet, but how about creating separate images for extensions and use those as "plug-in" containers to add additional PHP extensions, something like;

--volumes-from php_extension_a --volumes-from php_extension_b

Each "extension" container would expose the directory that the shared extension is located in as a volume (e.g. /usr/local/something/extension-a.so), including an extension-a.ini to enable the plugin.

People would be able to add extensions, simply by attaching extra containers to their setup.

Will probably work best when using in combination with fig, because you may end up needing a lot of containers 😄

[tianon]

Hah. So as a developer of a PHP app, I have to tell my users to launch extra containers with the PHP extensions my application needs in order to just get my application to actually run? That sounds pretty untenable. 😉

[thaJeztah]

Hm, yeah, I may be taking the modularity of Docker a bit "over the top" here. Otoh;

Orchestrate a stack of containers (NGINX + php-FPM + MySQL + MyApp) "works" (IMO)

Perhaps putting all non-default PHP extensions in a single image (docker-library/php-extensions-pack) could be an option? This image would be usable for all current permutations of the PHP image (CLI, php-apache)

[md5]

It appears that you can do --enable-soap=shared and that the conventional difference between --enable-* and --with-* is whether the extension uses external libraries or not.

I'm going to submit another PR shortly to change SOAP support to a shared extension instead of building it statically.