36 a 0, con 5 abstenciones. Esa fue la votación de septiembre de 2025 para dejar de recomendar PECL y mandar a todo el mundo a PIE, el PHP Installer for Extensions. Trece meses después, apostaría a que la mayoría de los Dockerfiles que mantienes siguen teniendo una línea pecl install, y entiendo por qué. Mi tesis es que deberías arrancar esas líneas este trimestre: el RFC decidió no poner fecha de retirada, así que el momento lo eliges tú, y quienes cambian primero son los que deciden cómo estará el ecosistema cuando llegue el resto.

El argumento contrario es sólido, así que le doy todo su peso. El RFC solo cambió el mensaje. PECL sigue funcionando, no hay nada programado para apagarse, y retirar el sitio o la herramienta exigiría otro RFC que nadie ha escrito todavía. Además, no todos los paquetes de PECL han dado el salto: PIE solo encuentra extensiones publicadas en Packagist con "type": "php-ext" en su composer.json, así que si una de las tuyas no se ha portado, te toca seguir con PECL para ese build. Esperar hoy no cuesta nada. Una persona sensata con el backlog lleno dice "luego" y sigue con su sprint.

Aquí es donde yo lo veo distinto. Ese paquete que falta es justo la razón para migrar ya, porque es precisamente lo que necesitas descubrir. Cambia una imagen de CI a PIE, mira qué instalación falla y tendrás una lista exacta de extensiones cuyos mantenedores necesitan un empujoncito o un pull request. Para quien mantiene una extensión, el arreglo es sobre todo un manifiesto: un nombre, el tipo php-ext (o php-ext-zend), una licencia, una restricción de versión de PHP y un bloque php-ext opcional con claves como extension-name y configure-options. Eso es una tarde de trabajo de alguien, y una issue educada de un usuario que de verdad lo ha probado vale más que otro año de silencio. Si no puedes esperar al mantenedor, pie repository:add vcs te desbloquea mientras tanto.

La ergonomía del día a día también juega a favor del cambio. Los nombres pasan a estilo Composer, así que xdebug se convierte en xdebug/xdebug, y el descubrimiento se traslada a packagist.org/extensions, que resulta de lo más familiar para cualquiera que haya escrito composer require más veces de las que ha comido. Lo que más me gusta es que PIE escribe el INI por ti. En la guía que leí, hecha con PIE 1.5.2 sobre PHP 8.3, creó un archivo en conf.d con priority=80 y una línea extension=, y luego informó de que el módulo estaba habilitado y cargado. He visto más de un incidente de madrugada que se reducía a un .so que compilaba a la perfección y que nunca llegó a activarse. Esa familia de bugs acaba de encogerse.

Para contenedores, el patrón de la documentación oficial monta el binario desde la imagen ghcr.io/php/pie:bin con un bind mount durante un único paso RUN, así que PIE nunca acaba en tu imagen final, y opciones como --auto-install-build-tools y --auto-install-system-dependencies responden a las preguntas que, si no, dejarían colgado un build no interactivo. En una máquina con varias versiones de PHP, --with-php-config te permite apuntar a php-config8.2 mientras PIE se ejecuta en cualquier versión a partir de la 8.1, y muestra la instalación de destino al principio de cada comando. Eso es mucho mejor que la vieja costumbre de adivinar qué phpize aparecía primero en el PATH.

No todo está pulido, y prefiero que te enteres de las asperezas por mí y no por el diff de tu gestión de configuración. La desinstalación borra el .so pero deja el archivo INI con la línea comentada y una notita de "removed by PIE". Me parece una decisión defendible, porque borrar un archivo que quizá editaste a mano sería peor, pero quienes usan Ansible o Puppet verán drift y necesitarán una regla de limpieza. También vas a necesitar root, porque el módulo va directo al directorio de extensiones del sistema, y la documentación dice poco sobre permisos. Las extensiones incluidas en PHP, como gd o mysqli, quedan fuera de su alcance, así que docker-php-ext-install conserva su trabajo. Nada de esto te impide desplegar.

En el fondo, lo que defiendo va de quién se mueve primero. Una deprecación sin fecha límite solo se completa si los usuarios generan la presión que habría generado una fecha, y el ecosistema llega a Packagist a base de un CI fallido y una issue amable cada vez. La gente de Go diría que ellos nunca han necesitado un paso de compilación para esto. Vale, nosotros tenemos phpize, y por fin al menos se ejecuta solo.

Te dejo con una pregunta. ¿Cuál es la extensión de tu stack que mantiene viva una línea pecl install, y se lo has dicho ya a su mantenedor? Me encantaría ver la lista en los comentarios, porque sospecho que es más corta de lo que todos pensamos.