On Thu, 27 Sep 2012 21:10:40 -0700, Tyler Romeo <tylerromeo(a)gmail.com>
wrote:
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?
In the end it should be both. A web-based system to install extensions
for
normal users. And cli scripts to install extensions for users maintaining
piles of wikis.
- Extensions should probably have some sort of
manifest file. What
format should it be in and what information should it contain?
I think Chad
(^demon) was the the one focusing on this area. We should ask
him what his plans were.
- 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.
It should be a real registry of extensions.
- 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.
To be done properly this is going
to require tying into core to use and
configure extensions in a different way. You also should not have to
manually install an extension to get a user-friendly way to install
extensions. So this should most definitely be part of core.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen
<daniel(a)nadir-seen-fire.com
wrote:
> On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger
> <mah(a)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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…
>
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]