I didn't see this mentioned in the RfC, so: is the plan to have a hard dependency upon composer? And if yes, why?
Topic on Talk:Requests for comment/Extension management with Composer
Well, I'm not sure I understand your question as to what you are referring to as "hard dependency upon composer" but I think the RFC itself made it clear that it is about "Extension management with Composer" which means that the Composer is an integral part of the RFC.
Let me rephrase my question: Will composer be required to install extensions?
+1 to this question. I will vehemently oppose this RFC if composer is a requirement/prerequisite to installing extensions, as we cannot guarantee that everyone has it (especially on shared hosts where the end user has incredibly limited access, and no, telling them to host elsewhere is not a viable option especially if our software currently works on their host without composer).
If composer is an optional (but recommended) component that makes extension management easier, then I'm looking forward to see how this develops, but only then.
I might have misread the RFC but it states clearly as "Extension management with Composer" not without.
Also, I far as I understand, this RFC is not about an obligation (or "hard dependency") but rather a general proposal as to how dependencies can be specified and integrate within MediaWiki.
If you think that you have a better way of defining dependencies that do not require Composer, I would suggest to open a similar RFC to this one that would allow to make dependency management within a MediaWiki environment "hassle free" because until now (after 10+ years development) MW has not been able to provide an viable solution for extension or extension developers.
It is not inteded that Composer be a hard requirement. It will be on top of the existing way of installing extensions. So if you want do it manually, you still can and the process will not get any more complicated. But if the RfC is implemented, you can take the alternative route via the extension installer.
Also, I'd like to see the architecture of the extension manater built in such a way that it's possible to change the mechanism that handles dependency management. So it should be possible to adapt the extension manager to a different "engine".
However, I think we should agree on one engine (hence Composer) and not plan for a whole bunch of solutions intially, to keep things within a reasonable scope and timeframe.
I would agree that Composer is a sane choice here -- it's in use in quite a few other places (user familiarity), it's developed by a dedicated team (well tested and supported), and it should be pretty easy to build additional UI on top of it (for whenever we get around to an Extension manager). Rolling our own dependency manager "just cause" is something that should be avoided when good FOSS alternatives already exist.