Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125753
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 05 Oct 2024 21:25:12 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <cdbc3c06-7369-49d1-a794-06568cea4be7@app.fastmail.com>
In-Reply-To: <FB303710-75A5-447E-9A6C-DCF4FD956542@koalephant.com>
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <FB303710-75A5-447E-9A6C-DCF4FD956542@koalephant.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote:
>> On 3 Oct 2024, at 01:48, Larry Garfield <larry@garfieldtech.com> wrot=
e:
>>=20
>> =EF=BB=BFSince Jim's RFC proposal was criticized for being too vague,=
 I hereby offer a somewhat more prescriptive policy proposal on using 3r=
d party code.  (With JIm's blessing.)  It's still more heuristics than r=
ules, but I think that's the right approach generally.  It also includes=
 a voting mechanism to resolve edge cases when they come up.
>>=20
>> I'm sure we'll bikeshed it to death, but please keep an open mind abo=
ut the concept in the first place.  PHP is more than just php-src, and t=
hat'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.
>>=20
>> https://wiki.php.net/rfc/third-party-code
>>=20
>> *Puts on trusty flame-retardant suit*
>>=20
>> --=20
>>  Larry Garfield
>>  larry@garfieldtech.com
>>=20
>
> Hi Larry,
>
> Can you expand a bit more on this item from the exclusion list?
>
>> The library is a =E2=80=9Cfull=E2=80=9D application or framework.
> To me that would mean anything that can be executed itself (be it a we=
b=20
> app, a command like tool or daemon, etc.
>
> But then you specifically say Composer and PHPUnit and Psalm and=20
> PHPstan are explicitly allowed... aren't all of them "full"=20
> applications, because  they can be executed in and of themselves.
>
> So, can you perhaps define what you mean by "full application" a littl=
e=20
> 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 re=
built the main website using Laravel, the Symfony folks would feel sligh=
ted.  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 ge=
t constant "well why not Wordpress?" questions.  Etc.

While I feel that concern is sometimes over-blown, I do believe it is va=
lid.  Notably, the "big name communities" tend to also be complete, inte=
grated solutions, and those also tend to be where there's more active co=
mpetition.  Eg, there's only one meaningful Yaml implementation the mark=
et, and two UUID libraries worth mentioning.  But there's literally doze=
ns of "frameworks" or "CMSes" to get mad at us.

So banning "full" frameworks is my attempt at steering clear of the appe=
arance of that kind of favoritism.  Showing favoritism for Composer or X=
debug is, well, there's no competition to complain.  PHPUnit is technica=
lly 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 w=
e 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 so=
meone 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 R=
FC, case by case.

I'm open to better ways to define what "full" means here if anyone has s=
uggestions.

--Larry Garfield