36 to 0, with 5 abstentions. That was the vote in September 2025 to stop recommending PECL and point everyone at PIE, the PHP Installer for Extensions. Thirteen months later I'd bet most of the Dockerfiles you own still have a pecl install line in them, and I understand why. My argument is that you should rip those lines out this quarter, because the RFC's choice to set no removal date leaves the timing up to you, and the early switchers are the ones who get to decide how the ecosystem looks when the rest of us show up.

The counter-argument is strong, so I'll give it full weight. The RFC changed the messaging only. PECL still works, nothing is scheduled to be switched off, and removing the site or the tool would take a separate RFC that nobody has written yet. On top of that, not every PECL package has made the move: PIE only finds extensions published on Packagist with "type": "php-ext" in their composer.json, so if one of yours hasn't been ported, you're stuck on PECL for that build. Waiting costs nothing today. A sensible person with a backlog says "later" and gets on with their sprint.

Here's where I land differently. That missing package is exactly the reason to migrate now, because it's the thing you need to find out about. Swap a CI image to PIE, see which install fails, and you'll have a precise list of extensions whose maintainers need a nudge or a pull request. For an extension author the fix is mostly a manifest: a name, the php-ext type (or php-ext-zend), a license, a PHP constraint and an optional php-ext block with keys like extension-name and configure-options. That's an afternoon of someone's time, and a polite issue from a user who actually tried is worth more than another year of silence. If you can't wait for the maintainer, pie repository:add vcs gets you unblocked in the meantime.

The day-to-day ergonomics also argue for switching. Names become Composer-style, so xdebug turns into xdebug/xdebug, and discovery moves to packagist.org/extensions, which feels like home for anyone who has typed composer require more often than they've eaten lunch. The part I like most is that PIE writes the INI for you. In the walkthrough I read, built against PIE 1.5.2 on PHP 8.3, it dropped a conf.d file with priority=80 and an extension= line, then reported the module as enabled and loaded. I've watched more than one late-night incident come down to a .so that compiled perfectly and was never switched on. That bug class just gets smaller.

For containers, the pattern in the official docs bind-mounts the binary from the ghcr.io/php/pie:bin image for a single RUN step, so PIE never lands in your final image, and flags like --auto-install-build-tools and --auto-install-system-dependencies answer the prompts that would otherwise hang a non-interactive build. On a box with several PHP versions, --with-php-config lets you aim at php-config8.2 while PIE itself runs on anything from 8.1 up, and it prints the target installation at the top of every command. That beats the old routine of guessing which phpize was first on the PATH.

It isn't all polish, and I'd rather you hear about the rough edges from me than from your config management diff. Uninstall removes the .so but leaves the INI file behind with the line commented out and a little "removed by PIE" note. I think that's a defensible choice, since deleting a file you might have hand-edited would be worse, but Ansible and Puppet users will see drift and need a cleanup rule. You'll also want root, because the module goes straight into the system extension directory, and the docs don't say much about privileges. Bundled extensions such as gd or mysqli are out of scope too, so docker-php-ext-install keeps its job. None of this stops you from shipping.

So the case I'm making is mostly about who moves first. A deprecation with no deadline only finishes if consumers create the pressure that a date would have created, and the ecosystem gets to Packagist one failed CI run and one friendly issue at a time. Go folks would point out that they never needed a compiler step for this. Fine, we have phpize, and now at least it runs itself.

So here's my question. What's the one extension in your stack that's keeping a pecl install line alive, and have you told its maintainer yet? I'd like to see the list in the comments, because I suspect it's shorter than any of us think.