Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125369
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 31 Aug 2024 15:46:50 +0200
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 "Jim Winstead" <jimw@trainedmonkey.com>, internals@lists.php.net
Message-ID: <98b12de8-5398-4038-9ae6-3dc6377d69cc@app.fastmail.com>
In-Reply-To: <27cbee89-093f-4903-baec-a10058370c33@gmx.de>
References: <9791621c-1313-4306-bc6a-5dd789f2b2df@gmx.de>
 <51FA7D6F-09F6-4267-9B57-5CBD42EA898C@cmpct.info>
 <57156bdd-cf93-404f-a10c-cd842bd7bb92@app.fastmail.com>
 <27cbee89-093f-4903-baec-a10058370c33@gmx.de>
Subject: Re: [PHP-DEV] What to do with ext/snmp?
Content-Type: multipart/alternative;
 boundary=71d22600dd734cacb5cdaea5c09ff4f3
From: rob@bottled.codes ("Rob Landers")

--71d22600dd734cacb5cdaea5c09ff4f3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 30, 2024, at 20:13, Christoph M. Becker wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote:
>=20
> [snip]
>=20
> And generally, while there are many well maintained extensions on PECL,
> most (i.e. way more than half of the extension there) are outright
> abandoned, dead or half-dead, a lot of the latter barely kept alive by
> Remi Collet.  A next generation PECL (installer) will not change this;
> only people who actively care about these extension could, if these
> people have knowledge of PHP extension development.
>=20
> I'm not saying that all PECL extensions deserve to be kept alive; there
> are good reasons for many to have been abandoned, e.g. because they we=
re
> built on no longer supported libraries, are generally not useful
> anymore, or would be written in PHP nowadays (e.g. ext/dbase).
>=20
> Instead I'm saying that we should be careful to unbundle extensions.
> This should probably seen as a last resort if we absolutely can't
> maintain the extension any longer, or it doesn't make sense to do that.
> I'm not sure yet that ext/snmp falls into this category.
>=20
> It's easy to vote "yes, unbundle this extension" if you've never used
> the extension and are not planning to do so in the future.  It may be a
> death sentence, though.
>=20
> Christoph
>=20

I went over to pecl to see how hard it was to create a new extension (af=
ter being prompted by Gina to submit my GMP operator stuff as a pecl ext=
ension). It appears to be very involved with a checkmark:

"I have already discussed the topic of maintaining and/or adding a PECL =
extension on the pecl-dev@lists.php.net mailing list, and we determined =
it's time for me to have a PECL account"

I, personally, can't imagine going through such a process. Not only do y=
ou have to convince gate-keepers you don't know to share your extension =
with (which higher up on the page says your code should be complete), bu=
t also convince end-users to use your extension. The barrier of entry is=
 high, when it would be much easier to just create a repository and inst=
ructions; effectively making discovery of interesting php extensions nea=
rly impossible.

If you are using something like Docker containers, there is https://gith=
ub.com/mlocati/docker-php-extension-installer which go so far as to inst=
all extensions from github (and apply patches) if they aren't updated/av=
ailable in pecl (example: memcached + php 8 had an issue that was fixed =
on github but didn't get an update on pecl for nearly a year, IIRC).

I'm pretty excited about pecl's replacement (how is that going anyway?) =
and hope it will be easier to create, maintain, and distribute extension=
s with.

In other words, I emphatically agree that moving extensions out of core =
and into pecl would be a death sentence.

=E2=80=94 Rob
--71d22600dd734cacb5cdaea5c09ff4f3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Fri, Aug 30,=
 2024, at 20:13, Christoph M. Becker wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 30.08.2024 at 19:05, Jim Winstead wr=
ote:<br></div><div><br></div><div>[snip]<br></div><div><br></div><div>An=
d generally, while there are many well maintained extensions on PECL,<br=
></div><div>most (i.e. way more than half of the extension there) are ou=
tright<br></div><div>abandoned, dead or half-dead, a lot of the latter b=
arely kept alive by<br></div><div>Remi Collet.&nbsp; A next generation P=
ECL (installer) will not change this;<br></div><div>only people who acti=
vely care about these extension could, if these<br></div><div>people hav=
e knowledge of PHP extension development.<br></div><div><br></div><div>I=
'm not saying that all PECL extensions deserve to be kept alive; there<b=
r></div><div>are good reasons for many to have been abandoned, e.g. beca=
use they were<br></div><div>built on no longer supported libraries, are =
generally not useful<br></div><div>anymore, or would be written in PHP n=
owadays (e.g. ext/dbase).<br></div><div><br></div><div>Instead I'm sayin=
g that we should be careful to unbundle extensions.<br></div><div>This s=
hould probably seen as a last resort if we absolutely can't<br></div><di=
v>maintain the extension any longer, or it doesn't make sense to do that=
.<br></div><div>I'm not sure yet that ext/snmp falls into this category.=
<br></div><div><br></div><div>It's easy to vote "yes, unbundle this exte=
nsion" if you've never used<br></div><div>the extension and are not plan=
ning to do so in the future.&nbsp; It may be a<br></div><div>death sente=
nce, though.<br></div><div><br></div><div>Christoph<br></div><div><br></=
div></blockquote><div><br></div><div>I went over to pecl to see how hard=
 it was to create a new extension (after being prompted by Gina to submi=
t my GMP operator stuff as a pecl extension). It appears to be very invo=
lved with a checkmark:<br></div><div><br></div><div>"I have already disc=
ussed the topic of maintaining and/or adding a PECL extension on the <a =
href=3D"mailto:pecl-dev@lists.php.net">pecl-dev@lists.php.net</a> mailin=
g list, and we determined it's time for me to have a PECL account"<br></=
div><div><br></div><div>I, personally, can't imagine going through such =
a process. Not only do you have to convince gate-keepers you don't know =
to share your extension with (which higher up on the page says your code=
 should be complete), but also convince end-users to use your extension.=
 The barrier of entry is high, when it would be much easier to just crea=
te a repository and instructions; effectively making discovery of intere=
sting php extensions nearly impossible.<br></div><div><br></div><div>If =
you are using something like Docker containers, there is&nbsp;<a href=3D=
"https://github.com/mlocati/docker-php-extension-installer">https://gith=
ub.com/mlocati/docker-php-extension-installer</a>&nbsp;which go so far a=
s to install extensions from github (and apply patches) if they aren't u=
pdated/available in pecl (example: memcached + php 8 had an issue that w=
as fixed on github but didn't get an update on pecl for nearly a year, I=
IRC).<br></div><div><br></div><div>I'm pretty excited about pecl's repla=
cement (how is that going anyway?) and hope it will be easier to create,=
 maintain, and distribute extensions with.<br></div><div><br></div><div>=
In other words, I emphatically agree that moving extensions out of core =
and into pecl would be a death sentence.</div><div><br></div><div id=3D"=
sig121229152">=E2=80=94 Rob<br></div></body></html>
--71d22600dd734cacb5cdaea5c09ff4f3--