> On May 18, 2023, at 10:27 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > 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.
There is at least a 3rd way. 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. 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 — by its very nature — to provide a single "baseline" that everyone can expect, a benefit of PEAR you noted above. > On May 18, 2023, at 10:43 AM, Reinis Rozitis <r...@roze.lv> wrote: > > 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 — compared to the hundreds (1000s?) of extensions they will not — 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. Technically both statements are correct, but practically speaking neither are realistic approaches to solving current day needs. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
