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 scripts? - 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.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger mah@everybody.org wrote:
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 infrastructure.
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 briefly, 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?
Mark.
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l