Hi, Thanks for your elaborated inside but somehow this doesn't tell the whole story. Take for example our extension (SMW but others are welcome as well) which depends on libraries and other extensions as well. I don't think it is practical nor good practice to have a user to write down each dependency and start kicking the git downland for each of them just to figure out at some point that s(he) missed something or caught the wrong hash tag and suddenly finds him/herself in a dependency nightmare. Knowing that I can specify what version works with which library and have tool that lets me forget about any of the dependency is what I want, I don't need a WMF special tool that may or may not work in future. I don't want a tool that increase technical debt on my end and using Composer (which is supported by more developers than WMF can hire) creates a certain confidence that the tool does what it is claimed for namely a tool to resolve dependencies. Having Composer resolving dependencies and at the same to put it into the right place (thanks for the `mediawiki-extension` type) together with a PSR-4 autoloader is the icing on the cake to make our extension deployable. If your extension does not depend on anything then this is good but not all extension are going for the golden goal of putting code in one line (or for that matter in one include folder). Some extensions try to isolate code by its responsibility and do make an effort to separate those into different components, arguing that only MW can strive towards "Librarization" is a bit short-sighted. Cheers On 2/15/15, Daniel Friesen <daniel(a)nadir-seen-fire.com> wrote: > On 2015-02-14 1:23 PM, Gergo Tisza wrote: >> ​This seems to have significant overlap with >> https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_man… >> . > As I mentioned this tool is a workaround to deal with current reality. > Not the "grand way forward". > Whenever that happens, the tool will disappear. > > The goal here is to make it so that whenever I (or someone else) has to > mange the extensions of an extension (setting up a staging wiki for a > client project, upgrading the extensions on one of the wiki I host, or > helping reprap.org upgrade) today, the job is easier to do until we have > a nice web interface for it. > >> Personally I think we should standardize around one tool and Composer >> seems >> the best positioned for that. So instead of maintaining N competing >> solutions with different strengths and weaknesses and leave the user to >> ponder which one to use, I think it would make more sense to focus on the >> holes in the Composer workflow and write small tools to plug them (e.g. a >> web interface to use Composer on servers without a shell access, or a way >> to disable/re-enable extensions without fully uninstalling them). > I don't believe that composer is the grand way forward. > -- TL;DR -- > I do believe that composer is a great way to use 3rd party extensions. > However I do not believe it is the way forward in extension installation. > > > Besides other things like all our extensions being hosted by a third > party and mixed in with libraries where they don't belong. Composer > doesn't even expose all the data we need to do a PROPER extension > management interface. > > i18n-ed name and description, extension type, and MediaWiki.org docs > primarily, but there will likely be more. > -- / TL;DR -- > >> In that spirit, maybe writing a composer.json (or composer.lock) generator >> could be a good way of making the extension + git branch selection user >> friendly? Once you know which version of which extension to install, >> Composer should be able to do the job. The generator could even be a web >> service with a nice GUI, like the short url builder (which rocks by the >> way, thanks for maintaining it!) > As I don't believe composer is the right way forward, building something > to try and get everyone to use it would be counter-productive. > > Anyways we likely wouldn't get all extensions to start using it. We have > over 600 extensions. And not everyone even buys into composer. > I'd still have the same problem. > > Even if it did work I'd end up creating new problems for myself. Now > every time I want to install 'ParserFunctions' I'd have to look up what > the composer name for it is. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi, I certainly don't want to drag this discussion but please let me clarify: It is possible but the MediaWikiVersionFetcher in ComposerHookHandler is only loaded by Composer starting with MW 1.25 [0] allowing for such check to take place but since we need to support MW 1.19 we cannot not leverage on that. We currently have ~72% coverage which makes testing a crucial part to ensure that previous and upcoming releases can be supported (for 1.25 we already run into some failing integration tests allowing for a prediction of a potential issue) other extensions of the same family have an even higher coverage rate which helps us to prognosticate whether a tested MW version can be supported or not, and of course such effort is not feasible for every extension. Yes, we are in agreement that an interface (including search, status update etc.) is necessary to make the user experience more pleasant for one or a bundle of extensions. I just don't want to see that dependency management suddenly becomes a trifle where the management of dependencies in itself is reinvented. [0] https://github.com/wikimedia/mediawiki/blob/master/composer.json#L45 Cheers On 2/15/15, Daniel Friesen <daniel(a)nadir-seen-fire.com> wrote: > On 2015-02-14 11:30 PM, James HK wrote: >> Hi, >> >>> Extensions/plugins are not libraries. >>> Frankly I want to give whoever built the addition to Composer that >>> allows packages to install as WordPress plugins and MediaWiki extensions >>> a good kick. >> Thanks for your elaborated inside but somehow this doesn't tell the whole >> story. >> >> Take for example our extension (SMW but others are welcome as well) >> which depends on libraries and other extensions as well. I don't think >> it is practical nor good practice to have a user to write down each >> dependency and start kicking the git downland for each of them just to >> figure out at some point that s(he) missed something or caught the >> wrong hash tag and suddenly finds him/herself in a dependency >> nightmare. >> >> Knowing that I can specify what version works with which library and >> have tool that lets me forget about any of the dependency is what I >> want, I don't need a WMF special tool that may or may not work in >> future. >> >> I don't want a tool that increase technical debt on my end and using >> Composer (which is supported by more developers than WMF can hire) >> creates a certain confidence that the tool does what it is claimed for >> namely a tool to resolve dependencies. >> >> Having Composer resolving dependencies and at the same to put it into >> the right place (thanks for the `mediawiki-extension` type) together >> with a PSR-4 autoloader is the icing on the cake to make our extension >> deployable. >> >> If your extension does not depend on anything then this is good but >> not all extension are going for the golden goal of putting code in one >> line (or for that matter in one include folder). >> >> Some extensions try to isolate code by its responsibility and do make >> an effort to separate those into different components, arguing that >> only MW can strive towards "Librarization" is a bit short-sighted. >> >> Cheers > git vs. composer is a false dichotomy. > > I don't believe that using git and ExtensionDistributor tarballs forever > is the correct way forward. > But I also do not believe shoving all our extensions into composer is > the correct way to fix that either. > > Composer doesn't fix all the issues and doesn't expose data needed to > build a proper system. > And it creates release restrictions (do real releases [maintain an > explicit version, follow semver] and tag them), which not every > extension needs and many authors don't want to deal with, which > precludes its use as the primary extension installation system. > > ---- > We need a proper interface and system for Extension management (and by > extension, configuration management). > > Some notes: > - It needs to support the requirements of everything from Semantic > MediaWiki to a lowly extension like Poem. > - The interface must not be English only, extension names/descriptions > for uninstalled extensions should be translated for every extension that > will be translated on Special:Version when the extension is installed. > - Extensions should be categorized in the same way they are on > Special:Version. > - A search interface is necessary for installing new extensions. > - It should automatically install composer libraries (even if the > ---- > > It would also be short sited to believe that a system built as a simple > wrapper around composer could solve all the version related issues we have. > Besides dep-hell, extensions also have incompatibilities with MediaWiki > releases themselves. > > > > The improving extension management RFC is a step forward in one part of > this (a proper way to declare compatibility). > > However a proper system would also involve running tests for extensions > and accepting reports of success or failure with a version of an > extension from users. > > All 3 sources of data would be exposed in the same API a MediaWiki > install's extension management page uses to search and query data about > extensions. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l