2013/7/22 Ryan Lane rlane32@gmail.com
For pure PHP libraries, they could be distributed like pure PHP libraries usually are. They can be packaged for multiple distros and be available via apt/yum/composer (or pear). Having them as MediaWiki extensions is somewhat awkward.
Yes, agree on that.
How does splitting extensions apart make it easier to check this during CI? Is there some automated way to do this when they are split, but not when they are together?
Yes. Assume you have class Ext which relies on class Core, but class Core should not rely on class Ext, because they are on different architectural levels. If Ext and Core are together, your CI will load them both and you won't notice if you access Ext from Core. No error is thrown. If Core is not together with Ext, then unit-testing Core will not load Ext. A call to Core will fail, and your CI will discover the error. The split helps keeping the architectural integrity of the code, and avoids it being
My concern was increasing complexity for admins with no effort towards decreasing it. Composer may indeed be an answer to some of the issues. From an admin's perspective using composer shouldn't be much harder than what they are currently expected to do and it would simplify the extension process.
Yes, I think so too. Composer could be a viable option, and within Wikidata we are quite happy with it. We would recommend adoption by the wider community. If the wider community chooses another solution for the dependency problem, we will adapt Wikibase to it too.
Cheers, Denny