On Thu, 18 May 2023 at 14:12, Deleu <deleu...@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]
