Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120342
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv> <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
 <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
In-Reply-To: <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
Date: Thu, 18 May 2023 12:27:12 -0300
Message-ID: <CADK1yXJPyAes4UeNSTasX_ri4yJrLfSVhg7W=RL1iYknBRT6Wg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006c131b05fbf97238"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: deleugyn@gmail.com (Deleu)

--0000000000006c131b05fbf97238
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 18, 2023 at 11:27=E2=80=AFAM Rowan Tommins <rowan.collins@gmail=
.com>
wrote:

> On Thu, 18 May 2023 at 14:12, Deleu <deleugyn@gmail.com> wrote:
>
> > > Or PEAR?
> > > Like that particular path_join() request is exactly
> > >
> >
> https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Ut=
il.html#methodbuildPath
> >
> >
> > I have worked with PHP for 14 years now and I know nothing about PEAR. =
It
> > either says something about me or about PEAR.
> >
>
>
> For many years PEAR was the official package repository for PHP. The clie=
nt
> was shipped with every install of PHP, and still serves as the basis for
> PECL, the official distribution for PHP extensions.
>
> From the point of most users, it has been entirely replaced by Composer,
> and I think some of the reasons for that are very relevant to this
> discussion:
>
> - PEAR required a package to be installed globally on a server; Composer
> allows (and encourages) it to be local to a particular project
> - PEAR was a "walled garden" - you had to request permission to publish a
> new package, or take over an existing one; Composer is a "bazaar" - anyon=
e
> can publish a package to Packagist, and projects can be forked
> - PEAR tried to be a cohesive ecosystem - it had a unified coding standar=
d,
> and a strong policy of package interoperability, aiming for a common "fee=
l"
> across all packages; Composer leaves developers to combine packages howev=
er
> they want
>
> 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:
>
> - 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 li=
ke
> Guzzle and Monolog; and smaller utilities that do one task well, like
> Ramsey/UUID
>

Thanks for the history lesson, this is super useful information, indeed.
Monolog is a great example of what PHP is missing - a single library for a
purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog is
considered to be The Logging PHP Library.

Guzzle is a near 2nd, but not quite there, especially after Symfony built
their own HTTP Client and further drove the community split. Laravel has an
amazing `Arr` class that wraps most of PHP's array_* standard library and I
love it and find it amazing, but it's a niche community within PHP.
Newcomers might get exposed to community debates[1] that end up driving
them away from taking advantage of a better array_* suite. Laravel's `Arr`
class also didn't get scrutinized by PHP RFC so there's no way to know
whether it's all good, some good or all bad.


>
> There are two ways I can see a "standard PHP package" working:
>
> - As a server-wide install, part of the distributed PHP. That inherits al=
l
> 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 al=
l
> the packages that are already out there.
>
> Bottom line, I think there is some merit in having part of the standard
> library be written in PHP rather than C, but we'd still want to be very
> conservative in what went in there, because most of the downsides of
> locking it to the PHP release cycle would still be there, and Composer
> seems to be serving the community pretty well for a lot of functionality.
>

> Regards,
> --
> Rowan Tommins
> [IMSoP]


I also see both options for this to work, but honestly I have no strong
feelings either way. For me it's pretty clear that a set of Composer
packages offering standard libraries under the PHP namespace and limited to
what gets approved by RFCs would be a lot different from all the packages
that are all there because it takes away all the time and energy
collectively spent in evaluating options and their reputations. We can get
started with what PHP offers by default and delay the evaluation process
until the PHP standard library no longer supports the use case. It's the
standard option and is covered by PHP's reputation. If your use case is not
standard, you might reach for a community-provided library that enhances
the standard library needs or build your own instead of always having to
use a community-provided library or build your own.

I also like the option of bundling it together with PHP, but that would
take some effort on PHP's Core Developers and I'd rather take the benefits
of having a PHP Standard Composer Package than to risk not having it
because it increases Core Developers' maintenance burden. The nice thing
about it is that if the idea works out great, a new RFC can be written to
bring the package into core and have that decision voted individually on
its own merits.

Finally, one awesome aspect I also see is that when time comes to
deprecate, abandon or "fix" design flaws in the PHP Standard Library,
regardless of whether it's bundled or a composer package, it can always be
ejected into a composer package. If 20 years from now there's a major
"legacy" project with a heavy dependency on something that PHP decides to
deprecate, they can just fork the package and embed it with their
application. One can argue that maybe we can do that today as long as we
write a custom PHP extension, but then comes the burden of PHP developers
having to know how to develop C and use PHP's extension system to try and
bring back functionality that was dropped from the language.


--=20
Marco Deleu

--0000000000006c131b05fbf97238--