Hey,
Finding a way to separate MW the library from MW the application may be a
solution to this conflict. I don't think this
would be a trivial
project, but it doesn't seem impossible either.
That'd be fanatic if it happened for many other reasons as well. For all
intents and purposes it is a big caste in the sky though. I expect this to
not happen in the coming years, unless there is a big shift in opinion on
what constitutes good software design and architecture in the community.
The side effect is that it removed the ability to use Composer to
manage external components used by MW the library
which is Tyler's
proposed use case [0].
If the core community actually gets to a point where potential usage of
third party libraries via Composer is actually taken seriously, this will
indeed need to be tackled. I do not think we are quite there yet. For
instance, if we go down this road, getting a clone of MW will no longer be
sufficient to have your wiki run, as some libraries will first need to be
obtained. This forces change to very basic workflow. People who dislike
Composer will thus scream murder. Hence I tend to regard this as a moot
point for now. Though lets pretend this has already bee taken care off and
look at solutions to the technical problem.
One approach, that is a lot more feasible then making MediaWiki (partially)
library like, is to specify the MW dependencies somewhere else. Not in
composer.json. Then when you install MediaWiki, these dependencies get
added automatically to composer.json. And when you update it, new ones also
get added. In a way, this is similar to the generation of LocalSettings.
This is the approach I'd be investigating further if we actual where at a
point where a technical solution is needed.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--