On Fri, 8 Dec 2023, Thomas Hruska wrote: > On 12/5/2023 8:45 AM, Derick Rethans wrote: > > > > Within the PHP Foundation, we have been talking for a while as what > > to do with PECL, and its website. > > > > The code is old, and hard to maintain. And the database is full of > > mojibake. It is also an outdated method of installing things, > > especially because userland code is so much easier to handle through > > Composer. > > > > Through the Sovereign Tech Fund (https://www.sovereigntechfund.de/) > > the Foundation has acquired some funding to improve this situation. > > > > Hence, to start of replacing PECL with something applicable for this > > decade, we started working on a requirements document: > > > > https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo > > > > In this first stage, we would like to invite you in commenting on > > the document (either inline, or here). > > > > Please keep in mind that this is a requirements document, and should > > not contain either design or implementation details. Once we have > > thought about these details as well, this will be turned into an > > RFC. > > My only thought about this is that the current PECL ecosystem existed > (and exists) as an "official repository" long before GitHub and other > options existed. The new tool should be able to pull in "unofficial" > packages too that don't depend on going through an approval process. > Of course, warning the user that "installing packages from unofficial > channels is potentially dangerous" before blindly marching forward.
The intention is that without any registry, there is no such thing as an "official package" any more. And the idea is that the tool can install packages from any compatible GitHub repository (initially). It is therefore important that we have at least the chcking of signatures in place for these packages, which is something that I also cover in the RFC. > Every extension author would then have to build Windows (and maybe > other OS) binaries themselves and deploy them in their own package > repositories. That might annoy some people and reduce the amount of > Windows support that exists, but the automated Windows PECL build > system has been broken for a VERY long time now, which already makes > extension development for Windows rather difficult. For some of my extensions, I already have a GHA that builds the Windows binaries. My intention is to extend these to make them generic, and handle that for maintainers, or at least have the skeleton set up for them. > This approach would largely remove pecl.php.net from the picture. > The only reason for it to continue to exist would be to support older > PHP and also function as an archive. A simple JSON file of official > packages on GitHub (or elsewhere) is all that would be required to > replace the entire PECL website. I am not proposing to shutdown the existing PECL website, instead, I envision it becoming read only first, and then after a while we can come up with a solution to transition the still active packages to the new way™. cheers, Derick
-- PECL development discussion Mailing List (https://pecl.php.net/) To unsubscribe, visit: https://www.php.net/unsub.php
