Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120353
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\))
Date: Thu, 18 May 2023 21:48:20 -0400
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv>
 <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
 <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
Message-ID: <4CC2548B-280C-4DD8-8E61-44640A03EBE8@newclarity.net>
Subject: Re: [PHP-DEV] PHP Package for PHP
From: mike@newclarity.net (Mike Schinkel)

> On May 18, 2023, at 10:27 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On the one hand, PEAR was a single "baseline" that everyone expected; =
on
> the other hand, packages tended to be slow to adapt to new needs and
> fashions, and inflexible to different environments. So instead, people
> moved to:
>=20
> - Frameworks; which themselves have mostly adopted a "component-based"
> approach interoperating via Composer packages
> - Non-framework groups like The League of Extraordinary Packages
> https://thephpleague.com/
> - Single packages that have become de facto standards - large projects =
like
> Guzzle and Monolog; and smaller utilities that do one task well, like
> Ramsey/UUID
>=20
> There are two ways I can see a "standard PHP package" working:
>=20
> - As a server-wide install, part of the distributed PHP. That inherits =
all
> the downsides of PEAR, but might be appropriate for a fairly small =
subset
> of really low-level functions.
> - As a set of Composer packages, managed completely outside the PHP
> lifecycle, in which case it's not clear how it would be different from =
all
> the packages that are already out there.

There is at least a 3rd way.=20

There could be server-wide installs with site-root overrides similar to =
how .htaccess works with Apache where a `.php` file (or some other name) =
in the site root could be used to provide overrides for the standard PHP =
library to allow sites to fix bugs, use a newer version, etc.=20

This would allow site owners to resolve PHP standard library related =
issues with sites on managed servers where the managed host will not =
allow server-wide install to be modified.

> Composer seems to be serving the community pretty well for a lot of
> functionality.

Except for Composer's lack of ability =E2=80=94 by its very nature =E2=80=94=
 to provide a single "baseline" that everyone can expect, a benefit of =
PEAR you noted above.=20

> On May 18, 2023, at 10:43 AM, Reinis Rozitis <r@roze.lv> wrote:
>=20
> There is usually the argument - "if this is not in core no one (people =
on shared environments/hosting) won't be able to use it" and so on..

Many orgs prefer managed hosting so as not to have to pay for system =
administer expertise on staff, and few (any?) managed hosts will modify =
their installs to include more than the few highly popular extensions =
from PECL.

>  The counter to that are things like Imagick / redis / memcache(d) / =
APCu which are vastly popular but still live outside core (obviously =
those are not language rather than engine features).

The list of extensions managed hosts will consider installing is so =
small =E2=80=94 compared to the hundreds (1000s?) of extensions they =
will not =E2=80=94 so pointing to the few outliers that can live outside =
core as evidence of developer's ability to address their needs with them =
is much like arguing the US Constitution can be amended to solve =
existing political problems.=20

Technically both statements are correct, but practically speaking =
neither are realistic approaches to solving current day needs.=20

OTOH, a standard library in core written in PHP that could allow for =
polyfills for future C-in-core changes, a lower bar for implementing =
additions to core (and thus a way to expand those who can actually =
contribute to core), and a starting place for anything that could be =
written in PHP to be written in PHP so as not to require updating and =
testing C code seems to have many benefits.  #jmtcw

-Mike=