On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote: >> On 3 Oct 2024, at 01:48, Larry Garfield <la...@garfieldtech.com> wrote: >> >> Since Jim's RFC proposal was criticized for being too vague, I hereby offer >> a somewhat more prescriptive policy proposal on using 3rd party code. (With >> JIm's blessing.) It's still more heuristics than rules, but I think that's >> the right approach generally. It also includes a voting mechanism to >> resolve edge cases when they come up. >> >> I'm sure we'll bikeshed it to death, but please keep an open mind about the >> concept in the first place. PHP is more than just php-src, and that's a >> good thing. We need to catch up with that reality, while at the same time >> maintaining a reasonable neutrality about projects Internals doesn't manage >> directly. >> >> https://wiki.php.net/rfc/third-party-code >> >> *Puts on trusty flame-retardant suit* >> >> -- >> Larry Garfield >> la...@garfieldtech.com >> > > Hi Larry, > > Can you expand a bit more on this item from the exclusion list? > >> The library is a “full” application or framework. > To me that would mean anything that can be executed itself (be it a web > app, a command like tool or daemon, etc. > > But then you specifically say Composer and PHPUnit and Psalm and > PHPstan are explicitly allowed... aren't all of them "full" > applications, because they can be executed in and of themselves. > > So, can you perhaps define what you mean by "full application" a little > more clearly? > > Cheers > > Stephen
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc. While I feel that concern is sometimes over-blown, I do believe it is valid. Notably, the "big name communities" tend to also be complete, integrated solutions, and those also tend to be where there's more active competition. Eg, there's only one meaningful Yaml implementation the market, and two UUID libraries worth mentioning. But there's literally dozens of "frameworks" or "CMSes" to get mad at us. So banning "full" frameworks is my attempt at steering clear of the appearance of that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no competition to complain. PHPUnit is technically not the only testing framework on the market, but it has north of 90% share (and is used internally by some of the few others). But showing favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier. A full framework also makes maintenance potentially more challenging, as we it's a much larger external moving target than a UUID library that we could easily fork in a worst case scenario. So... I don't really have a solid, clear definition of what constitutes a "full framework", because in the market, there isn't one. I'm sure someone could make a compelling argument that Slim isn't a full framework, for instance, although I don't think I'd agree with it. It is inherently squishy, which is why these are intended as heuristics, not strict rules, and when it's unclear we can bring it to a vote via RFC, case by case. I'm open to better ways to define what "full" means here if anyone has suggestions. --Larry Garfield
