On Thu, 27 Sep 2012 21:10:40 -0700, Tyler Romeo <[email protected]>
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 | [email protected]
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen
<[email protected]
wrote:
On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger
<[email protected]>
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
[email protected]
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
