-
Notifications
You must be signed in to change notification settings - Fork 39
feat(composer): install PECL extension #286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a0a3461
to
34e3873
Compare
lib/composer
Outdated
install_pecl_extension $ext "$ext_version" "$CACHE_DIR" | indent | ||
fi | ||
|
||
# TODO I don't think this instruction should be executed for all extensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have a question about this instruction. But the question also stands for the script version on master
.. Do you know its purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is more a question for @Soulou right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try to remove it and see if all extensions we're officially supporting in our doc are building as expected.
I assume that some extensions will fail, since it requires external libs that we are packaging.
My guts feeling on this is that:
- All extensions which are not pre-packaged by us currently which do not require another external library should enter this new standard process
- All extensions which are installed automatically should keep being maintained.
- But installing
redis
andmongodb
doesn't really make sense it's not used that often, I would stop installing them automatically - APCU is a automatic code compilation caching optimization, we should keep installing it by default.
- But installing
- All extensions which are pre-packaged by us should keep using
fetch_package
, so we need to identify them:
[ KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/amqp → PECL extension requiring external lib, we must keep supporting it
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/apcu → PECL only, but should be automatically installed, so let's keep it fast by prebuilding it
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/apfd → PECL only, drop pre-packaging
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/blackfire → Third party lib, we need to keep it
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/ds → PECL only, drop pre-packaging
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/event → Requiring webp
lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/igbinary → Non PECL
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/imagick → PECL only
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/lua → Requiring installation of LUA
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/mcrypt → PECL only
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/memcached → External lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/mongodb → External lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/redis → External lib
@EtienneM is my analysis clear, does it match your point of view?
lib/pecl
Outdated
|
||
pushd ${extension_name}-${version} > /dev/null | ||
/app/vendor/php/bin/phpize > /dev/null | ||
./configure --with-php-config=/app/vendor/php/bin/php-config --with-${extension_name}=${build_dir}/.apt/usr > /dev/null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the option --with-${extension_name}
is not always useful, or may be named differently. How could we make this configurable? Via an environment variable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's more: some extensions use the extension=whatever.so
directive while some others use the zend_extension=whatever.so
.
For now I planned to use a (rather uglyish) case
statement to handle all this. But I wanted to discuss it also.
That was before the decision to first have infosec have a look at it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no way to know if an extension need the zen_extension or the extension directive from PECL (i.e. xdebug needs a zen_extension directive but nothing is mentionned on the pecl repository). I think defining env variables to configure the --with-${extension_name}
and the extension
/ zen_extension
directives could be a solution to this
The fact that some extensions are really old has been raised in the original issue and it was agreed that we wouldn't care about it. Yet, infosec was supposed to review all of them and give us a go. |
We should also handle the case where there is something like this in the {
"require": {
"ext-mongodb": "*",
"ext-imagick": "*",
...
}
} The |
FYI, support for the We'll have to decide if we rely on the apt-buildpack or on custom instructions to handle the dependencies of such extensions :) |
…ibaio installed via apt buildpack libaio and oracle-client must be cached to avoid download at each deploy
…ng oci8 extensions
feat(oci8): support `oci8` extensions
|
Tested with scalingo-22 PHP 8.1 / 8.2 All with success |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is working with OCI8 LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, we have some kind of extra support for oci8 as it has been request by a CST customer, am I right? Other people would need to use the apt buildpack?
fetch_package "$base_url" "${engine}-${version}" "$location" | ||
} | ||
|
||
function has_package() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
best practice: I'm not sure about what this function does. Maybe add a comment or rename it so that it's clearer? If I understand correctly it makes a HEAD request to our object storage to check if the given package exists, which means that we pre-compiled the extension, isn't it?
At the time of changing our approach from allow-listing specific extension, to support all extensions from PECL, our Product Management identified a customer lead requiring the availability of OCI8 PHP extension. The work was done to achieve both supporting PECL extensions, and ensuring the specific OCI8 extension would work. I currently lack the knowledge to comment whether this could have been achieved by using the apt buildpack, or not. |
Yes you're right |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for a first version.
(some comments still need to be addressed IMHO :))
Co-authored-by: Étienne M. <EtienneM@users.noreply.github.com>
@Frzk you're right, I missed some from Étienne :-D |
lib/composer
Outdated
install_pecl_extension $ext "$ext_version" "$CACHE_DIR" | indent | ||
fi | ||
|
||
# TODO I don't think this instruction should be executed for all extensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try to remove it and see if all extensions we're officially supporting in our doc are building as expected.
I assume that some extensions will fail, since it requires external libs that we are packaging.
My guts feeling on this is that:
- All extensions which are not pre-packaged by us currently which do not require another external library should enter this new standard process
- All extensions which are installed automatically should keep being maintained.
- But installing
redis
andmongodb
doesn't really make sense it's not used that often, I would stop installing them automatically - APCU is a automatic code compilation caching optimization, we should keep installing it by default.
- But installing
- All extensions which are pre-packaged by us should keep using
fetch_package
, so we need to identify them:
[ KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/amqp → PECL extension requiring external lib, we must keep supporting it
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/apcu → PECL only, but should be automatically installed, so let's keep it fast by prebuilding it
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/apfd → PECL only, drop pre-packaging
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/blackfire → Third party lib, we need to keep it
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/ds → PECL only, drop pre-packaging
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/event → Requiring webp
lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/igbinary → Non PECL
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/imagick → PECL only
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/lua → Requiring installation of LUA
[DROP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/mcrypt → PECL only
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/memcached → External lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/mongodb → External lib
[KEEP] https://github.com/Scalingo/php-buildpack/blob/master/support/ext/redis → External lib
@EtienneM is my analysis clear, does it match your point of view?
I went through the PECL download statistics (https://pecl.php.net/package-stats.php) and tested a bunch of the packages from there. The PHP info is here: https://biniou.osc-fr1.scalingo.io/. Some of these packages are really old so I didn't tested them. I tried to find some packages that are still maintained:
libyaml-dev
librabbitmq-dev
Fix #249