Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121987
MIME-Version: 1.0
References: <8d4bcca5-a2ce-5ee1-1aed-02076539433a@php.net> <c6af7028-a731-4087-8245-40e543d05eb8@wikimedia.org>
 <0b25cbe2-1986-c499-defc-a556114853df@php.net> <b6a8095d-a9d0-494a-bfa9-70cff24417dc@app.fastmail.com>
In-Reply-To: <b6a8095d-a9d0-494a-bfa9-70cff24417dc@app.fastmail.com>
Date: Mon, 11 Dec 2023 23:55:16 +0700
Message-ID: <CAEZPtU4gN7xpf7-Qt3+J86f=vDdKS2_ku_875dCrP_QNPJuB9Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001fbda4060c3ecd66"
Subject: Re: [PHP-DEV] New "PECL"
From: pierre.php@gmail.com (Pierre Joye)

--0000000000001fbda4060c3ecd66
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 11, 2023, 11:21 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Mon, Dec 11, 2023, at 9:46 AM, Derick Rethans wrote:
>
> > Yeah, I understand. And I feel the same. But if there is no registry (a
> > goal), then there is no way to find out which of your extension version
> > support a specific PHP version, without checking every tag in your
> > repository. That's not going to be fast.
> >
> > cheers,
> > Derick
>
> See, I think I disagree on this point.  Having a registry is table-stakes
> for package managers these days.  Composer, npm/yarn, whatever Python does
> this week, Cargo, Bundle, Maven/Gradle... a packager isn't complete without
> a registry.  The one exception is Go, and its approach is... just a mess,
> frankly.
>
> Whether PECLtng piggybacks on Packagist, self-hosts using something like
> Satis, or does a home-grown thing, I don't think a neo-PECL without a
> registry is a viable and sustainable way forward.  That needs to be in the
> initial design.
>

hi Larry,

you are fully right here.

On top of the already mentioned points, it brings visibility to extension
packages, which is a key factor to adoption at large.

It also helps for an automatic builds.

A service is also a must for automatic releases/triggers builds. You can
see this service with a github tag hook on pickleweb.

It is also quite a good thing to automate dependencies management. It could
be relatively straightforward to update them per distros, or windows (see
my earlier post, already managed using windows. php.net data).

Also without the services (implemented but no public packagist for
extensions yet), I think pickle already does 95% of it (including local
windows builds). Adding signature is relatively simple.

Important note, during pickle development, the number 1 request was to be
fully integrated with composer. it was not possible until composer v2,
plugin and custom tags.  Given that composer is the only used package
manager , it should be the way to go. To create something from scratch
without taking these points into accounts can only lead to a sub optimal
solution.

There are also development environments tools out there which could provide
relatively easily per project extensions management (either cli or pools).

PHP is not my primary platform anymore, business wise, however I am happy
to help if desired.  I can only, with a diplomatic emphasis, suggest to the
author to understand where the php ecosystem is (or was 3 years or more
ago).


best,
Pierre

>

--0000000000001fbda4060c3ecd66--