Re: [RFC][Vote] Policy on third party code
| From: | John Coggeshall | Date: | Mon, 11 Nov 2024 00:40:45 +0000 |
| Subject: | Re: [RFC][Vote] Policy on third party code | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125937@lists.php.net to get a copy of this message | ||
> 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