Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120340
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv> <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
In-Reply-To: <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
Date: Thu, 18 May 2023 15:27:28 +0100
Message-ID: <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000064673a05fbf89b10"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000064673a05fbf89b10
Content-Type: text/plain; charset="UTF-8"

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_Util.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 client
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" - anyone
can publish a package to Packagist, and projects can be forked
- PEAR tried to be a cohesive ecosystem - it had a unified coding standard,
and a strong policy of package interoperability, aiming for a common "feel"
across all packages; Composer leaves developers to combine packages however
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 like
Guzzle and Monolog; and smaller utilities that do one task well, like
Ramsey/UUID

There are two ways I can see a "standard PHP package" working:

- 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.

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]

--00000000000064673a05fbf89b10--