Add information about Composer and example of using it's autoloader

[jimwins]

Long past time that we included information about Composer in the documentation. Related PR for doc-base incoming.

[cmb69]

A bold move, Jim!

I'm somewhat concerned about opening a can of worms when merging this; I consider it quite likely that there quickly will be lots of PRs suggesting to add examples or even documentation about some packages, and then tooling, frameworks, IDEs, etc. Maybe we should consider defining the scope first; maybe we should handle this on a case by case basis; maybe we should instead link to some external sites (e.g. https://phptherightway.com/); maybe we should try to join forces?

In any way, we shouldn't introduce personalization into the PHP manual (e.g. no "you", but instead using passive voice).

[jimwins]

I think possibly having the problem of fending off too many contributions to the manual is vastly preferable to the existing problem of not acknowledging major chunks of the PHP ecosystem in the name of some sort of neutrality.

More here: https://trainedmonkey.com/2024/08/23/writing_documentation_in_anger

The PHP project is where we gather to join forces, I don't think these fundamentals should be left to external sites.

[cmb69]

I agree (also with your blog post), but we should properly discuss this, since there has been big drama a couple of years ago, and I would not like to see this happening again. Maybe there should even be an RFC about "endorsing third-party tools" (or so), to settle this topic once and for all.

cc @Crell

[Crell]

I completely agree with adding Composer references to the docs, for all the reasons @jimwins mentions. However, I also agree that we should probably not call out ramsey/uuid in particular as an example. Nothing against Ben, but that part is a much more slippery slope than composer (which has basically zero competition). A foo/bar package or similar is probably better.

As far as proper discussion, the most straightforward way would be an RFC "is it OK to talk about Composer in the docs? Y/N". (We did a similar RFC recently for linking to the Foundation site, which passed easily.) It should be a pretty easy RFC, and would quash any squeamishness about if it's OK or not.

[jimwins]

Thanks for linking to that other issue, that fills in a historical event I knew was out there but hadn't run across. As it happens, I have another related blog post:

https://trainedmonkey.com/2024/07/27/the_rules_can_matter

Here's a draft RFC that is broader than just asking for permission to mention Composer:

https://wiki.php.net/rfc/web-and-doc-use-not-endorsement

[cmb69]

RFC "is it OK to talk about Composer in the docs? Y/N"

Possible, but rather limited in scope, as follow-ups will surely come; from Jim's blog post:

I would love to add a chapter on static analysis tools. And another one about linting and refactoring tools. Maybe a chapter on frameworks.

And of course, there is the issue about actually using it. I think we're using Composer and a few packages already in different Web repos, but still not in some repos which could benefit from some tooling (see e.g. php/php-sdk-binary-tools#22 or php/php-sdk-binary-tools@78c9f7b, the latter being an issue detected with static analysis; or even https://externals.io/message/124843#124866).

[jrfnl]

... much more slippery slope than composer (which has basically zero competition).

Nothing against Composer, but in that case, what about PHIVE ? And shouldn't the history with PEAR and its installer be mentioned ?

I do see the slippery slope here, even in the mention of Composer.

[jimwins]

Nothing against Composer, but in that case, what about PHIVE ? And shouldn't the history with PEAR and its installer be mentioned ?

PEAR and a number of PEAR packages are mentioned in the documentation now, but it's an official PHP project (even if mostly dormant).

I'll discuss the slippery-slope argument in the discussion on internals now that the RFC is being discussed there.

[derickr]

I had not even heard of PHIVE. And PEAR is probably going to be mothballed into a static site.

I've written a more general thought on all of this: https://news-web.php.net/php.internals/125300

I completely agree with adding Composer references to the docs, for all the reasons @jimwins mentions. However, I also agree that we should probably not call out ramsey/uuid in particular as an example. Nothing against Ben, but that part is a much more slippery slope than composer (which has basically zero competition). A foo/bar package or similar is probably better.

Using foo/bar doesn't have any meaning for users. real packages do. Picking an example from a community member as opposed to a large opinionated frameworks makes perfect sense to me.

[cmb69]

I had not even heard of PHIVE.

Its main developer even has a php.net account (apparently for as long as you do). :)

I do see the slippery slope here, even in the mention of Composer.

I agree. It starts with Composer. Then someone asks "what does a composer do?" Right, he's writing a Symfony. And who would sing the overture? Lara Vel, of course! And it ain't over till the slim lady sings. ;)

[oladoyinbov]

It would be better to create a section on the PHP website homepage (at the footer section) to list out the most popular PHP frameworks and packages, you can check python.org for a good sample of what I am talking about.

Frameworks like Laravel, Symfony, CodeIgniter, CakePHP and Package Managers like Composer should be added to help beginners and the less informed access the PHP ecosystem more quickly.

[Girgias]

It would be better to create a section on the PHP website homepage (at the footer section) to list out the most popular PHP frameworks and packages, you can check python.org for a good sample of what I am talking about.

Frameworks like Laravel, Symfony, CodeIgniter, CakePHP and Package Managers like Composer should be added to help beginners and the less informed access the PHP ecosystem more quickly.

This is already being discussed on the Internals ML.