Hi, I certainly don't want to drag this discussion but please let me clarify:
> If I install mediawiki/[email protected] today with composer, it > will not tell me if it supports MediaWiki 1.16 nor will it tell me if it > supports MediaWiki 1.26. 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. > Practically no extension author bothers testing on each release how far > back their extension works. Or bother making a note of that which > composer or another program could read. > And it's impossible for them to know at the time of publishing a release > if a new release of MediaWiki will work with their extension or not. 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. > extension itself isn't published) automatically. Whether this is done by > integration of composer/composer or packaging libraries automatically on > the origin side. > - It should understand when it needs to take installation steps like > upgrading the database. 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 <[email protected]> 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 > extension itself isn't published) automatically. Whether this is done by > integration of composer/composer or packaging libraries automatically on > the origin side. > - It should understand when it needs to take installation steps like > upgrading the database. > ---- > > 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. > > If I install mediawiki/[email protected] today with composer, it > will not tell me if it supports MediaWiki 1.16 nor will it tell me if it > supports MediaWiki 1.26. > > Practically no extension author bothers testing on each release how far > back their extension works. Or bother making a note of that which > composer or another program could read. > And it's impossible for them to know at the time of publishing a release > if a new release of MediaWiki will work with their extension or not. > > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
