Stop compiling PHP extensions into the PHP binaries

[cweagans]

I know at least mcrypt is bundled into Travis' PHP installations, because that's the one that I care about. In any case, though, I think it makes much more sense to build PHP with the minimal amount of stuff built into the binary, and then give users a way to turn on and off extensions (just via php.ini is totally adequate).

You could do this in a backward compatible way, too. mcrypt, as an example: since it's already enabled and bundled with PHP, when/if you switch to having it as an extension, you can just have it included in php.ini by default.

My use case is https://github.com/cweagans/mcrypt-polyfill (which is basically a way to provide the mcrypt_* functions backed by crypto libraries that are more actively maintained, namely OpenSSL), but I've seen other cases where being able to disable PHP extensions would be desirable. http://stackoverflow.com/questions/26237641/disable-core-php-extension-on-travis-ci is an example that wants to do this with the intl extension. Generally, if a PHP extension is optional, it should be possible to disable it for testing purposes.

Bonus points if you provide wrapper scripts to enable/disable PHP extensions, so that in my .travis.yml, I can just do:

before_script:
  - [ -z "${USE_MCRYPT}" ] || travis_disable_php_ext mcrypt

mcrypt should really be disabled by default, though. It's completely unmaintained, which is the entire reason I'm building mcrypt-polyfill. People shouldn't be depending on mcrypt for important things.

[j0k3r]

Any update on this? I would like to disable the tidy extension.

[danielstjules]

Interested in using this for https://github.com/danielstjules/Stringy as well so I can selectively disable mbstring for some jobs to ensure things work when polyfilled. :)

[lucasmichot]

Any news on this ?

[JordanRL]

👍

I have a library for doing arbitrary precision math (https://github.com/JordanRL/Fermat). For this library I have two extensions that I'm concerned with as far as testing goes:

ext-bcmath
ext-gmp

The code I have uses the gmp extension when dealing with integers (for speed), and this extension is included by default in Travis. It's somewhat nice that it is included, because Travis offers no good way to install PHP extensions without using sudo.

That said, my library polyfills in all cases where gmp is unavailable. Since it's always available on Travis, I have no way to get coverage for my polyfill code.

[BenMorel]

Any news on this? Plenty of meaningful examples have been given in this thread already, it would be nice to have some feedback from Travis!

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[cweagans]

This issue hasn't been resolved.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[BenMorel]

This issue still hasn't been resolved.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a new one after. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[BenMorel]

Still unresolved, stalie! See you in 3 months.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a new one after. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[cweagans]

Still a problem.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[j0k3r]

Still not.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[giggsey]

Still not fixed.

👋 See you in 3 months.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[giggsey]

3 months already?

Where does the time go.

[cweagans]

If this hasn't been solved after 4 years, I don't have a lot of hope that it will get resolved at all. I've moved off of Travis, so I'm going to go ahead and unsubscribe from this issue. Hope y'all get what you need here.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[BenMorel]

Still not resolved, clutterbot!

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[BenMorel]

Shame on stalebot. Still not resolved!