Why PECL is deprecated in favor of this?

[Luniterse]

I came here from PECL site's deprecation notice. I've looked in discussions and issues in case anyone already bothered with the question, and linked document in that issue doesn't explain significant benefits from switching from PECL to PIE. We're using PECL in our Docker PHP images based on official PHP-FPM ones and while extensions are installed there by one line like
pecl install imagick redis && docker-php-ext-enable imagick redis
your tool suggests doing this with minimum 8 lines. (It would be the same one line if pie was included in PHP-FPM images but I guess this is not the case.) Besides, if I understand correctly, this tool behaves like Composer by installing extensions from their authors' repositories and not from a centralized site with moderation by maintainers which brings many security problems. So why we should switch to PIE? What is real profit of it to end-users?

[asgrim]

Hi @Luniterse, thanks for the great question. There's a few reasons we've dropped PECL support in favour of PIE, primarily it is driven by ensuring we have a sustainable and modern infrastructure with PHP. PECL depends on a repository and infrastructure that is struggling, and difficult to maintain. In order to reduce maintenance effort, we have made a coordinated effort to introduce this new tool - PIE - which is based heavily on Composer, and thus uses the very well maintained Packagist.org infrastructure for package metadata. The PIE tool itself is being actively developed, primarily by me at the PHP Foundation, with an express goal of making extension management better and easier going forward, certainly easier that PECL ever was. The decision to deprecate PECL in favour of this more modern tooling was discussed on the mailing list, and the eventual RFC was accepted with 36 ayes, 0 nays, and 5 abstentions.

To address specific technical points you encountered:

[in Docker PHP images] extensions are installed there by one line like pecl install imagick redis && docker-php-ext-enable imagick redis your tool suggests doing this with minimum 8 lines.

It is actually still possible to use a single line like pie install phpredis/phpredis in your Docker images, but the 8-line example you linked to is a "best practices" approach; this does things like mount PIE into the layer to avoid PIE being in your final image (it's a build tool, not a runtime dependency), sets the DEBIAN_FRONTEND env, does apt updates/installs of dependencies etc, cleans up apt after, etc.

If you would like a MUCH simpler example, but with drawbacks/caveats that must be understood first, you could simplify this into something like:

COPY --from=ghcr.io/php/pie:bin /pie /usr/bin/pie
RUN pie install phpredis/phpredis

Which leads me neatly onto:

It would be the same one line if pie was included in PHP-FPM images but I guess this is not the case.

We actually discussed this quite heavily in docker-library/php#1554 and we did a lot of thinking/research about this. PECL/PEAR is indeed in the base PHP images provided by Docker, but that may actually be removed as PECL/PEAR are removed from PHP itself. Ultimately, PIE is specifically a build tool not a runtime tool, and as such should not be built into the final image - again, a best practice we recommend.

Besides, if I understand correctly, this tool behaves like Composer by installing extensions from their authors' repositories and not from a centralised site with moderation by maintainers which brings many security problems.

There isn't really moderation on pecl.php.net beyond an initial account approval. Once you have an account, in theory you could just publish anything you want. The same is true of Composer, but the moderation tools available to the Packagist repository are much more modern - and PIE takes advantage of that by using Composer internally. However, there is a good point here about supply chain security, and it's something that we are taking seriously, and both the PHP Foundation, and the Packagist team are actively looking into to improve this important aspect.

Finally, in order to alay any immediate concern, plans have not yet been made for a timeline to actually disable PECL repository. That is still a discussion to be had, but I think a reasonable approach would be to set a sunset timeline where PECL itself will be made "read only", and then eventually turned off, perhaps. But I stress - that's not a decision, just ideas, and still will need to be discussed.

I hope this helps, and I'm happy to clarify and help further if needed :)

[GromNaN]

I think a reasonable approach would be to set a sunset timeline where PECL itself will be made "read only", and then eventually turned off, perhaps.

I look forward to seeing PECL sunset. The process of manually uploading extensions to pecl.php.net is archaic. Security is so much better with PIE.

[kynx]

And if you need yet more historical context the ever-smart creator of phpunit has it in spades: https://phpunit.expert/articles/laying-the-past-to-rest.html