On Mon, 26 Aug 2024, Deleu wrote: > On Mon, Aug 26, 2024 at 3:12 PM Bob Weinand <bobw...@hotmail.com> wrote: > > > Thanks for bringing this up - I also suggest that we make this a > > binary choice - either we adopt the proposed language or its > > opposite. > > > > I.e. a rejection of this should codify that statement in the > > negative. > > > > I do in particular reject the notion that we should document > > third-party projects (usage for our infra is fine). > > > > The point of the PHP documentation is to describe the PHP runtime > > and PECL extensions, which are both officially distributed through > > php.net. > > > > Anything not related to these does not belong into the manual, much > > less into core documentation (like language/oop5 autoload.xml, to > > take the example from > > https://github.com/php/doc-en/pull/3677/files). > > > > Changing this current unwritten rule is an invitation to implicitly > > promote specific projects. The question is really where does it end? > > Would we for example also mention PSRs as "widely followed > > guidelines for interoperability" or something? It's a strong > > invitation for some scope creep. > > > > As such I strongly condemn the idea of inclusion of this guideline. > > > > There are, ultimately, enough ways for people to learn about the PHP > > ecosystem, the php.net documentation is none of them. If I go to > > php.net, it's because I want to learn about the runtime, not its > > ecosystem. > > > Since your message was somewhat ambiguous to me, I would like to take > this opportunity to request clarification from Jim. > > I read this RFC as an opportunity to allow community-driven PHP > projects to be embraced when it suits PHP's internals needs. For > instance, I remember a few years ago a conversation about rebuilding > the php.net website. The current "unwritten" rule was used to impose > that a new PHP website could not use any existing PHP Framework as to > not "endorse" any particular project. Same thing goes for the RFC > Voting process, PSRs, Composer, etc.
I think there is a difference between "using existing packages to make our life easier" and "we use this fully fledged framework". The latter should still not be a reasonable outcome here. > In a way, I agree with Bob's take that the php.net documentation > should not be used to *document* 3rd-party tooling, but my > interpretation of the RFC has nothing to do with documenting 3rd-party > tools but instead its about mentioning or even relying on them. No, it absolutely has something to do with that. There is no mention of Composer on php.net. That is ludicrous. Documenting *proprietary* installers (such as AMPSS as raised in https://github.com/php/doc-en/pull/1674) is probably something I *won't* favour. Explaining how to install PHP with homebrew, apt or yum makes perfect sense to me. Nobody really ought to go to www.php.net/download and compile PHP themselves. But that's the only installation instructions that we have. cheers, Derick
