Talk:Requests for comment/Improving extension management

Yet another concept
I find this very confusing. Extensions are essentially libraries (or PHP packages). In the olden days, those were managed by the system administrator in the form of distribution-specific packages. For some time now, composer is needed and needs to be mastered. And on top of that yet another concept? I think the way forward should be to reduce the complexity.

Wiki X requires the libraries mediawiki 1.25, mw-parserfunctions 1.3, mw-math 1.9 and mw-superextension 2.39. mw-superextension 2.39's  would depend on mediawiki >= 1.23 (everything's fine) or mediawiki = 1.23 (installation/update fails). The installer spits out  and an   that after reading   calls the mediawiki library's   function.

Developers who are used to composer know what is happening and where to look if something does not work. --Tim&#160;Landscheidt 04:12, 26 January 2015 (UTC)


 * It does seem to me that Composer's "require" could handle both the supported MediaWiki version(s) and dependent extensions problems. It would however require all extensions to add Composer support. --BDavis (WMF) (talk) 08:02, 26 January 2015 (UTC)


 * I don't agree that extensions are essentially libraries. Libraries have code and just require an autoloader. Extensions have code with an autoloader, but they also need to register hooks, special pages, API modules, and a bunch more. Composer has never and should never be required for sysadmins who use the tarball. It is recommended for developers, but developers != sysadmins.
 * I'll add a section on why I don't think composer is an adequate solution to this issue. Legoktm (talk) 08:13, 26 January 2015 (UTC)


 * Registering can happen with a file autoload. Most Wikidata code works that way, as do for example UniversalLanguageSelector and Cldr. I'm not saying that makes composer ideal for extension management, but it can work. Adrian Heine (WMDE) (talk) 09:20, 27 January 2015 (UTC)
 * That works, but it's also one of the issues I outlined that composer combines the install and enable steps into one. Legoktm (talk) 17:17, 27 January 2015 (UTC)
 * Agreed. Adrian Heine (WMDE) (talk) 09:19, 29 January 2015 (UTC)

Packaging
IMHO all this borders uselessness if Debian etc. packagers don't agree to use the new system. Can you email mediawiki-distributors please? (I see you already sent an update for 1.25 dependencies, that's great! I hope they reply...) --Nemo 09:26, 26 January 2015 (UTC)
 * sent! Legoktm (talk) 18:10, 26 January 2015 (UTC)

Duplicate
Can you please merge your own Requests for comment/Configuration database 2 to this one, or summarise its outcome here? This is the fourth RfC proposing something of this kind, if I count correctly; it's hard to see or understand the progress of the discussion. --Nemo 09:26, 26 January 2015 (UTC)
 * Configuration database 2 is about storing all wiki settings in a database (or other backend) and allowing for on-wiki editing of those settings. This RfC just includes an enable/disable web interface, and doesn't cover any other configuration settings. Legoktm (talk) 17:41, 26 January 2015 (UTC)
 * So nothing at all from the discussions in the past RfC applies to this RfC? Feels like we're running in circles, just that. I'd like to discover that 4 years of discussion brought us something. :( --Nemo 17:49, 26 January 2015 (UTC)
 * No, I just meant that the Config DB 2 RfC was separate. I think all of the past RfCs have basically outlined the same issues (some that have now been resolved by other RfCs), but each one has had a different solution. I definitely learned things from past RfCs and incorporated them into mine though, so I don't think the 4 years of discussion were a waste. Legoktm (talk) 19:24, 26 January 2015 (UTC)