Make available extensions discoverable

[sophiewigmore]

Currently, we point users who want to know what extensions are available at the old V2 compilation code lists of extensions. It would be great if we had a better way to make the list of extensions available for each version we support, right here in the buildpack. Ideally, in the release notes.

We should look into if there's a nice way to get this list from the PHP artifacts we support and add it to the release notes somehow, or at a minimum give users a simpler way to understand extension options.

[joshuatcasey]

What if php-dist prints out the list of files underneath PHP_EXTENSION_DIR? This could be hidden behind BP_LOG_LEVEL=DEBUG. For php-dist@c33e9fa this prints:

[builder]     Found PHP extensions directory: /layers/paketo-buildpacks_php-dist/php/lib/php/extensions/no-debug-non-zts-20200930
[builder]       Listing PHP extensions
[builder]         - amqp.so
[builder]         - apcu.so
[builder]         - bz2.so
[builder]         - curl.so
[builder]         - dba.so
[builder]         - enchant.so
[builder]         - exif.so
[builder]         - fileinfo.so
[builder]         - ftp.so
[builder]         - gd.so
[builder]         - gettext.so
[builder]         - gmp.so
[builder]         - gnupg.so
[builder]         - igbinary.so
[builder]         - imagick.so
[builder]         - imap.so
[builder]         - ldap.so
[builder]         - lzf.so
[builder]         - mailparse.so
[builder]         - maxminddb.so
[builder]         - mbstring.so
[builder]         - memcached.so
[builder]         - mongodb.so
[builder]         - msgpack.so
[builder]         - mysqli.so
[builder]         - oauth.so
[builder]         - odbc.so
[builder]         - opcache.so
[builder]         - openssl.so
[builder]         - pcntl.so
[builder]         - pdo.so
[builder]         - pdo_firebird.so
[builder]         - pdo_mysql.so
[builder]         - pdo_odbc.so
[builder]         - pdo_pgsql.so
[builder]         - pdo_sqlite.so
[builder]         - pdo_sqlsrv.so
[builder]         - pgsql.so
[builder]         - phpiredis.so
[builder]         - pspell.so
[builder]         - psr.so
[builder]         - rdkafka.so
[builder]         - readline.so
[builder]         - redis.so
[builder]         - shmop.so
[builder]         - snmp.so
[builder]         - soap.so
[builder]         - sockets.so
[builder]         - sodium.so
[builder]         - solr.so
[builder]         - sqlsrv.so
[builder]         - ssh2.so
[builder]         - sysvmsg.so
[builder]         - sysvsem.so
[builder]         - sysvshm.so
[builder]         - tideways_xhprof.so
[builder]         - tidy.so
[builder]         - xdebug.so
[builder]         - xsl.so
[builder]         - yaf.so
[builder]         - yaml.so
[builder]         - zip.so
[builder]         - zlib.so

[joshuatcasey]

Other (logging) options:

• Add an exec.d script written in PHP to print out the list of extensions when the container runs
• Add a process type that would print out the list of extensions if that process type was chosen for execution

[sophiewigmore]

Having it in the logs is a little confusing to me, because it's a list of the possible extensions someone *could use in their build, not the extensions that someone is using. I think making the extensions discoverable, to me, meant making it easier for someone trying to figure out if the extensions they want to use in their app are supported in the PHP distribution that we provide.

I suppose they could learn this information by doing a build, but I think it would be more helpful to have this information ahead of a build so they can be informed if the build will support their use case. Do you see what I mean?

Some kind of logging about the extensions could be helpful for other debugging cases though

[joshuatcasey]

@sophiewigmore Could you clarify it's a list of the possible extensions someone *could use in their build, not the extensions that someone is using.

I think we do want to show all possible extensions, so that application developers know what is available for them.

I really hesitate to put the list of extensions in the release notes for several reasons:

• This would mean php-dist is no longer able to use the standard workflow provided by paketo-buildpacks/github-config
• The available extensions are linked to the version of PHP, which is determined at build time. As of 4df84cc this buildpack supports six PHP versions, all of which might have different available extensions, so the release notes would need to capture the available extensions for each version.

I suspect application developers would be happy with a copy/paste command to retrieve the list of available extensions (if we added logging we could probably come up with such a command).

Another two options:

• Allow users to request extensions that could then be loaded up for them (we'd have to figure out where these extensions come from and whether this would work offline)
• Once this repo is responsible for its own dependency we may be able to make it really obvious in the compilation code where these extensions come from.

[sophiewigmore]

You are right, having multiple versions of PHP and listing out every extension list for every version could be a lot of information to have in the release notes. I think this could be simplified to look at by creating a table of all of the extensions like:

Extension	PHP 7.4	PHP 8.0	PHP 8.1
<some extension>		X	X

I'm not sold yet on the idea of a script because I suspect a user may want to know what extensions are available for them before they do a build (it's possible that they'd only want to check after a build has run and failed maybe). In order to check, they'll probably need to know the exact version of PHP that will get pulled into their build in order for the script to properly get the extensions. I'm just not sure I understand the logistic of how a script would work in this scenario.

[sophiewigmore]

Allow users to request extensions that could then be loaded up for them (we'd have to figure out where these extensions come from and whether this would work offline)

I think the team may have looked into this before but I can't recall why this wasn't ideal. @thitch97 or @arjun024 may know.

Once this repo is responsible for its own dependency we may be able to make it really obvious in the compilation code where these extensions come from.

^THIS! agreed

[joshuatcasey]

I'm not sold yet on the idea of a script because I suspect a user may want to know what extensions are available for them before they do a build...

This is a good callout. When I said "simple copy/paste command" I was thinking that would be a pack build command that would invoke the logging output given a particular version of PHP. A separate script would be brittle and undesirable.

Once this repo is responsible for its own dependency we may be able to make it really obvious in the compilation code where these extensions come from.

Ooooh, what if we put the list of extensions into the buildpack.toml? It is in some sense metadata about that dependency.

[joshuatcasey]

Blocking until we get the new Dependency Management system