Daniel makes some good points. However, we still do need some sort of
better extension installation system besides our current "clone and
require". So here's some things we might want to consider:
- Should this be a web-based system or something done with maintenance
- Extensions should probably have some sort of manifest file. What
format should it be in and what information should it contain?
- How would extensions be installed? Would the manifest file be made
public online and you just reference that file? Or maybe you just give the
URL of the git repo or tarball of the extension? Or maybe MediaWiki creates
some sort of repository that can be used? Most likely it'll be a
combination of the latter two.
- Would this extension system be part of the core, or an extension
itself? I personally would side with putting it in the core, but if we're
going truly modular some will argue otherwise.
Stevens Institute of Technology, Class of 2015
Major in Computer Science
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen <daniel(a)nadir-seen-fire.com
> On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger <mah(a)everybody.org>
> On 09/26/2012 01:54 PM, Krinkle wrote:
>>> We're going towards a flexible modular system, which
>>> means components have dependencies and build on each other - as opposed
>>> to just
>>> "being there".
>> This sounds great, but I do see an important missing piece of
>> First, I am absolutely in favor of a loosely-coupled, modular system
>> instead of just building a larger and larger core.
>> The problem, though, is that there is no way to install, use, or update
>> extensions apart from doing it by hand. Requiring the installation of
>> multiple modules by hand isn't going to lead to a thriving, modular
>> ecosystem. We need a dependency manager.
>> Thankfully, I think there is already a dependency manager that we can
>> build on.
>> I'm talking about Composer (http://getcomposer.org/
>> Of course, MediaWiki isn't aware of this dependency manager and so
>> MediaWiki's extensions aren't either. I've only looked at it
>> but it appears that adding support wouldn't be difficult at all -- it
>> would just mean adding a file to the git repository.
>> What do you think?
> We probably don't want to depend much on it.
> Composer is really a tool for 3rd party library installation. And
> extensions aren't 3rd party libraries.
> Some issues with Composer in this regard:
> - Composer is a CLI library install tool. Depending on it will very likely
> get in the way of offering web based extension installation like just about
> every other major CMS.
> - Composer installs libraries in some arbitrary path (default vendor/,
> requires setting an ENV var or cli parameter to change) and politely asks
> you to use it's method of autoloading. This means the usual way of handling
> extensions with our own dir and require_once is out of the door. This
> probably won't work at all without a severe hack since we setup things in a
> php file we always require. It will also probably completely break
> extension asset loading.
> - Composer is not a full-fledged typical package manager. You cannot do
> something like `php composer.phar install mediawiki/Extension-**ParserFunctions`
> you can only run `php composer.phar install` somewhere that a composer.json
> is defined. This means a few things:
> -- We can't make core depend on every extension so we will have to install
> with an individual extension as a base.
> -- This means you will have to install things by manually downloading
> some. And letting composer install others from within that extension.
> -- As a result of this Composer is going to try to install things in
> extensions/Foo/vendor/... this means our standard structure won't work.
> Worse Composer is not going to share things between extensions and probably
> won't work in the first place.
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name
> Wikitech-l mailing list