[SMW-devel] List composer packages used within MediaWiki
Hi, In order to free the end-user from handling and installing individual dependencies, Composer will be used as preferred installation method starting with SMW 1.9 and while end-users probably have less interest in what packages are installed, sometimes developers want to see information about installed packages therefore [1] can be used to list those information (together with type, version, last update, and dependencies) within a SpecialPage. PS: MW-core doesn't provide a sufficient hook for the Special:Version page that would allow to list package information therefore Special:ListComposerPackages is used instead. [1] https://github.com/mwjames/mw-composerpackages Cheers -- 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=63431311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] List composer packages used within MediaWiki
Hi Mark, I know what I need to make it work but the last time I tried to add something to MW-core it took 8 month so I'm rather reluctant to waste my time on MW-core issues. Cheers On 11/26/13, Mark A. Hershberger m...@everybody.org wrote: On 11/25/2013 12:59 PM, James HK wrote: PS: MW-core doesn't provide a sufficient hook for the Special:Version page that would allow to list package information therefore Special:ListComposerPackages is used instead. 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? -- http://hexmode.com/ When you are generous, you are not bestowing a gift, but repaying a debt. -- On Living Simply, St John Chrysostom -- 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=63431311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] List composer packages used within MediaWiki
On 11/25/2013 01:17 PM, James HK wrote: I know what I need to make it work but the last time I tried to add something to MW-core it took 8 month so I'm rather reluctant to waste my time on MW-core issues. I understand your reluctance. https://bugzilla.wikimedia.org/56455 is currently giving me grief. Still, If you can put something in gerrit, I'd love to advocate for it. If you just want to provide a patch to me, I can submit it -- naming you as the author or not as you like. Mark -- http://hexmode.com/ When you are generous, you are not bestowing a gift, but repaying a debt. -- On Living Simply, St John Chrysostom -- 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=63431311iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] List composer packages used within MediaWiki
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 --
Re: [SMW-devel] List composer packages used within MediaWiki
Hey, I had another idea related to the topic of this thread, though technically quite independent from (virtually all) the implementation needed for the other functionality described already. Have an API module that simply serves the composer.lock file. This can be implemented as trivially as reading the file and serving that, or perhaps doing a json parse in between and feeding the array to the MW API thing. In fact, I'd not go further and add additional things on top here, so it stays as simple as it can be for this use case. And if it is this trivial, it might be feasible to get it into MW core. Be warned, whoever implements this might be forever loved by Jamie Thingelstad (Wikiapiary). 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=63431311iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
