Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125492
Date: Tue, 10 Sep 2024 20:46:01 +0000
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Jim Winstead <jimw@trainedmonkey.com>, internals@lists.php.net
Subject: Re: [PHP-DEV] What to do with ext/snmp?
Message-ID: <Vk6SQnh3n0wWFW8G1Sop-c8QaZEZSbYfWa106Qax1FSiw3dRPzf4xRPu-I-v2HtpGvsFy-3X2x7pmMUzPpnhL_l7cLZ612ApF53Q0Bd50Xw=@gpb.moe>
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>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 30 August 2024 at 20:13, Christoph M. Becker <cmbecker69@gmx.de>=
 wrote:

> On 30.08.2024 at 19:05, Jim Winstead wrote:
>=20
> > Perhaps if the effort from the PHP Foundation to build a next-generatio=
n PECL bears fruit, an even harder look can be taken at migrating out even =
more of the extensions still living in the php-src tree. With some robust C=
I, care could be made to make sure changes in php-src that impact extension=
s is noticed and dealt with, but spinning them out on their own might make =
them easier for more people to contribute to and maintain.
>=20
>=20
> Let's see what happened with the latest unbundled extensions:
>=20
> * PHP 7.4 unbundled ext/wddx, ext/recode and ext/interbase; neither has
> any release on PECL; they are effectively dead. At least the latter is
> still barely maintained outside of PECL.
>=20
> * PHP 8.0 unbundled ext/xmlrpc, which had three releases, and given that
> I'm listed as maintainer, I'd say that extension is also dead.
>=20
> * PHP 8.4 unbundled imap and pspell. These had two releases each, but I
> wouldn't hold my breath for a third.
>=20
> * PHP 8.4 also unbundled oci8 and pdo_oci. The former has already been
> partially maintained on PECL. Regarding the latter Christoph Jones is
> struggling to keep it somewhat maintained (due to lack of time).
>=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 were
> 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

Arguably this is because PECL is a pain to use as a maintainer and that we =
use PECL as a "graveyard".

But it is my biggest belief that most extensions would be better outside th=
e php-src repo and live in PECL so they could be updated independently and =
not tied to the yearly PHP release schedule.
The fact that ext/cURL is not allowed to be updated in patch releases any m=
ore means that features in libcurl take *ageees* to get exposed in PHP.
It also prevents extensions to be properly refactored because they are boun=
d to the same BC policy as the PHP engine, which doesn't make a lot of sens=
e to me.
I could have cleaned-up ext/xml with all the weird "string method callables=
" used with xml_set_object() in 1 week by releasing 3 different versions on=
 PECL, instead of performing some refactoring and 1 RFCs. [1]
Or fix ext/dba and do a release without the absurd parameter type of dba_ke=
y_split().
Having the DOM extension in PECL and be able to just change the behaviour o=
f the legacy classes to fix them instead of creating a whole new hierarchy =
which slows down adoption could also have been prevented (if it is a good i=
dea) if it wasn't tied to PHP's release schedule and BC policy.
It would also permit extensions to follow semver while the engine continues=
 to have its own versioning system.

Having an extension be "bundled" doesn't even mean it is properly maintaine=
d, as neither ext/imap, ext/xmlrpc, or in this case ext/snmp are actually m=
aintained.

Having added support for PIE for ext/csv, which was very easy, [2] I hope w=
hen this tool is finally ready, and we ditch PECL, we will start unbundling=
 extensions so that they are not constrained by the PHP Engine release cycl=
e.


Best regards,

Gina P. Banyard

[1] https://wiki.php.net/rfc/deprecations_php_8_4#xml_set_object_and_xml_se=
t_handler_with_string_method_names
[2] https://gitlab.com/Girgias/csv-php-extension/-/commit/ab978521e4d3bde15=
b73838d4605c5e5178ba082