Hey James,
Great work!
And you beat me to it! I started working on the exact same thing yesterday.
You can currently observe the lack of code in my GitHub repo for this [0].
Though what you are currently going is only a subset of what I had in mind.
One can retrieve package info from Packagist (and perhaps the other
repositories listed in composer.json), which URLs like [1]. This can be
used to enrich the information of installed extensions (and perhaps other
packages as well), in particular with what the latest version is.
And when we know there is an update, we can actually show an update button,
that when clicked, causes the corresponding composer command to be
executed. Furthermore, we do not need to limit this to updating. We can
display a list of available MediaWiki extensions that are not installed
yet. A list of MediaWiki extensions can be obtained from Packagist via [2].
So I'm imagining having a "installed stuff" page, with tow sections: first
extensions, then libraries. A second page would be for "stuff that can be
installed". Perhaps this can be on the same special page but use tabs? That
question is getting a bit to UI for me.
At this point there is no way to filter by supported MW version, or to
specify this in the page definitions to begin with. I plan to investigate
this, though good if someone gets it done before me.
The two API urls from Packagist listed [1, 2] I got from the Packagist
maintainer after chatting with him. They are not documented, though are
supposed to be stable. Furthermore there is no way to get package info in
batch now, the .json urls need to be hit one by one.
Since MW 1.22 is going to ship with the barest beginnings of Composer
> support, I think we should extend Special:Version to support this.
>
> For now, though, we can add hooks -- do you have any suggestions?
>
If you go for what I just described, which I think we should (and if people
disagree, I'll be hacking up a proof of concept regardless), then putting
this all on Special:Version really makes no sense. Special:ExtensionManager
is what I came up with.
Having an additional list there might be nice, and can be done without to
much hassle, at least technically. There are quite some core people
screaming murder at libraries like Diff showing up on Special:Credits
(though being cynical about it, I'd not be surprised if they where actually
just upset about my name being there) already, so I'm with James in
thinking that attempting real integration here is likely to result in a lot
of wasted time and effort.
Perhaps it is more worthwhile to, when a nice little initial implementation
of extension management stuff on top of Composer is done, try getting that
extension bundled with core by default. In this case I figure putting it in
core even makes sense, as it is functionality one almost always desires.
That means adding new clean code to core though, which is like locking an
insentient person in a jail with some big bloke criminals. Poor code.
James: I outlined these ideas here in part so you could go ahead and do
more awesome stuff already. I might be able to get to poking more at this
tomorrow evening, though quite possibly only on Thursday. In any case, I'd
appreciate a heads up if you want to poke at any of the additional stuff
described, so we don't end up doing the exact same work there. I'm thinking
the functionality should be in the same component/repo, as it has quite
high cohesion and makes sense together functionality wise. Even if you
already end up implementing all of the things to be done here functionality
wise before I can get to it, I'd still like to contribute by improving some
things in the code. Like fixing some of those annoying naming issues you
currently have in there, mostly without even bothering you about them :D
Also, did you steal [3] from [4 and 5], or is this an instance where we
where also thinking the same thing, but I won the implementation race? This
shows clearly that the lack of decent interfaces in the i18n "component"
provides by core is a general issues for anyone working on top of MW. I
think a component that does the same for i18n as what WikibaseDatabase did
for db interaction is in order. I was planning to create that as soon as I
ran into the need of [4], [5] or similar somewhere else, though again, if
someone beats me to it, great.
[0] https://github.com/JeroenDeDauw/ExtensionManager
[1] https://packagist.org/packages/mediawiki/semantic-mediawiki.json
[2] https://packagist.org/packages/list.json?type=mediawiki-extension
[3]
https://github.com/mwjames/composer-packages/blob/master/src/ComposerPackages/TextBuilder.php
[4]
https://github.com/JeroenDeDauw/WikibaseQuery/blob/master/src/Wikibase/Query/MessageBuilder.php
[5]
https://github.com/JeroenDeDauw/WikibaseQuery/blob/master/src/Wikibase/Query/MessageTextBuilder.php
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
