Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125938
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 11 Nov 2024 00:03:42 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <2bdad6e0-e5e0-48a6-bbd3-b938804287ca@app.fastmail.com>
In-Reply-To: <3BE04517-DF71-401C-B29F-9BCBB0B16DB0@getmailspring.com>
References: <AF8C68C7-A2CD-47DA-9834-A5E5DB154ACE@php.net>
 <3BE04517-DF71-401C-B29F-9BCBB0B16DB0@getmailspring.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Policy on third party code
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Nov 10, 2024, at 6:40 PM, John Coggeshall wrote:
>> And we're in 2024 now and nobody writes PHP code without Composer. Without this change, we can't use any composer available library for PHP.NET sites, nor even mention it in the documentation.
>> That's bonkers.
>
> 100% agree with you. 
>
>> This is counter productive, because the current rule is: don't use anything, or mention anything, third party.
> Per the very first line of the RFC... 
>
>> The PHP project has had a long-standing but unwritten, vague, and inconsistently-applied proscription against mentioning or using third-party PHP projects, on the grounds that it implies some sort of endorsement over other third-party projects.
> I guess my point here is when I read this RFC it moves the needle from 
> "unwritten, vague, and inconsistently-applied" to a much more firm 
> "don't use them, don't talk about them" on frameworks -- which I think 
> is a mistake. It also seems entirely haphazard in the "what's allowed" 
> vs. "what's not". in terms of packages based on Larry's (probably 
> correct) opinion of what's mainstream as a solution for particular 
> problems.. All of this is wildly inconsistent is my point. Also what 
> happens if I decide to use a composer package component that's really a 
> part of Laravel or Symfony or ....? Is that allowed or not? 
>
> I wouldn't have even blinked on a "yes" vote here if the RFC was to 
> allow composer.. it's this other half-baked stuff that I am balking 
> at... I'd very much like to see this RFC stripped of those bits if 
> possible. 
>
> John

Hi John.

First off, the obligatory "it was open for discussion for a month, and now you mention this?"

Second, I'm not sure I really understand the objection here.  This RFC shifts the policy from

"You cannot use or mention anything 3rd party at all, especially a framework, except for where you asked forgiveness and not permission already"

to

"Here's guidelines for when you can use, reference, or use for marketing (3 different things) third party libraries without asking first, and here's a mechanism for if you want to ask for specific exceptions."

So if, hypothetically, someone wanted to rebuild bugs.php.net using Symfony (note: Please don't), that wouldn't be allowed by default... but they could post an RFC to ask for an exception.  (Whether it would pass is a different question.)  If the issue is just a single component... those are fine, and there's even a few Symfony components *already listed* as approved for use (because they're already in use).  So if someone wanted to use Symfony/Yaml on the docs site for some reason, they could just do it.

> I guess my point here is when I read this RFC it moves the needle from 
> "unwritten, vague, and inconsistently-applied" to a much more firm 
> "don't use them, don't talk about them" on frameworks 

This is... not true.

For using, yes, full frameworks are not allowed for the reasons stated.  Components are fine, though, and if someone wanted to RFC an exception for Symfony-based bugs.php.net, they can try.  That's more permissive than the current policy.

For documentation... it's no change from the current status quo.  If your concern is "zOMG, why can't we just tell people in the docs to use Symfony?", it's because someone else will immediately respond with "zOMG, why can't we just tell people to use Laravel instead?", and in a year or so someone will probably say "zOMG why can't we just tell people to use Tempest?"  And then we'd have to argue if CodeIgnighter is something we want to even acknowledge exists.  Full frameworks are a very, very active market, and I *agree* that we should try to avoid putting our thumb on the scales more than is necessary.  Though again, there's an RFC process for exceptions.

For marketing material, I quote:

"The library MAY be a Web Application, provided its mention clearly does not specifically endorse the Application. If many options exist in a space that bears mention, the most common should be given equal exposure."

So if, for example, we wanted to put up a "Yay, PHP 8.4" page that says "Laravel, Symfony, and Slim already support it!", *that is explicitly allowed*, as long as we don't play favorites.  That's contrary to the status quo, where even mentioning that they exist is disallowed.

The guidelines are not "haphazard".  They are carefully written to strike a balance, which is a different balance for different use cases.  They were adjusted based on feedback from several people, though not as many as I would have liked.  They are subject to adjustment over time via RFC, which is something the old policy as mum about (as it wasn't actually written down), so if you want to file an RFC to widen them a bit further, you can do that and let the voters do what they will.

So really, contrary to what you're saying, this RFC improves precisely the situation you're talking about in every way.  Perhaps not as much as you would like, but it still moves the needle closer to it.  I really don't have the stomach at the moment for litigating the "should we just go ahead and endorse some framework" question (I'm on team-no anyway), so I deliberately avoided that question when the main focus is to, as stated, let us mention Composer, PHPUnit, and other staples that have nowhere near the healthy competition that frameworks have.

--Larry Garfield