Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125754
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
Date: Sun, 6 Oct 2024 11:27:35 +0700
Message-ID: <20C9A459-1A23-4610-A7D9-99C2571672D2@koalephant.com>
References: <cdbc3c06-7369-49d1-a794-06568cea4be7@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
In-Reply-To: <cdbc3c06-7369-49d1-a794-06568cea4be7@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: php-lists@koalephant.com (Stephen Reay)




Sent from my iPhone
> On 6 Oct 2024, at 09:38, Larry Garfield <larry@garfieldtech.com> wrote:
>=20
> =EF=BB=BFOn Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote:
>>>> On 3 Oct 2024, at 01:48, Larry Garfield <larry@garfieldtech.com> wrote:=

>>>=20
>>> =EF=BB=BFSince Jim's RFC proposal was criticized for being too vague, I h=
ereby offer a somewhat more prescriptive policy proposal on using 3rd party c=
ode.  (With JIm's blessing.)  It's still more heuristics than rules, but I t=
hink that's the right approach generally.  It also includes a voting mechani=
sm to resolve edge cases when they come up.
>>>=20
>>> I'm sure we'll bikeshed it to death, but please keep an open mind about t=
he concept in the first place.  PHP is more than just php-src, and that's a g=
ood thing.  We need to catch up with that reality, while at the same time ma=
intaining a reasonable neutrality about projects Internals doesn't manage di=
rectly.
>>>=20
>>> https://wiki.php.net/rfc/third-party-code
>>>=20
>>> *Puts on trusty flame-retardant suit*
>>>=20
>>> --
>>> Larry Garfield
>>> larry@garfieldtech.com
>>>=20
>>=20
>> Hi Larry,
>>=20
>> Can you expand a bit more on this item from the exclusion list?
>>=20
>>> 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 web
>> app, a command like tool or daemon, etc.
>>=20
>> 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.
>>=20
>> So, can you perhaps define what you mean by "full application" a little
>> more clearly?
>>=20
>> Cheers
>>=20
>> Stephen
>=20
> 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 t=
he 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, th=
e Slim folks would get upset.  If we used Drupal, we'd get constant "well wh=
y not Wordpress?" questions.  Etc.
>=20
> While I feel that concern is sometimes over-blown, I do believe it is vali=
d.  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 UU=
ID libraries worth mentioning.  But there's literally dozens of "frameworks"=
 or "CMSes" to get mad at us.
>=20
> So banning "full" frameworks is my attempt at steering clear of the appear=
ance of that kind of favoritism.  Showing favoritism for Composer or Xdebug i=
s, 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.
>=20
> A full framework also makes maintenance potentially more challenging, as w=
e it's a much larger external moving target than a UUID library that we coul=
d easily fork in a worst case scenario.
>=20
> 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 c=
ould make a compelling argument that Slim isn't a full framework, for instan=
ce, although I don't think I'd agree with it.
>=20
> It is inherently squishy, which is why these are intended as heuristics, n=
ot strict rules, and when it's unclear we can bring it to a vote via RFC, ca=
se by case.
>=20
> I'm open to better ways to define what "full" means here if anyone has sug=
gestions.
>=20
> --Larry Garfield
>=20

Hi Larry,

Right I understand the motivation, it's just the phrasing that I think needs=
 to be clarified.

=46rom what you've said (which is kind of what I imagined you probably meant=
) I think it just needs to be clarified that the "full application" exclusio=
n is about *web* applications, and doesn't applying to command line tooling/=
utilities.

Cheers

Stephen=20=