Architecture meetings/RFC review 2014-05-30

'''19:00 UTC, Friday, 30 May, at.

Request for Comment to review

 * 1) https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration

Summary and logs
Meeting started by sumanah at 19:00:03 UTC. The full logs are available at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.log.html .


 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/Performance_guidelines_discussion_2014-05-30 (sumanah, 19:00:41)
 * Extension registration (sumanah, 19:00:46)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration (sumanah, 19:01:33)
 * http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076662.html post by Kunal ( legoktm ) about his RfC (sumanah, 19:02:04)
 * "Extensions register a lot of things, like classes, hooks, special pages, configuration options, and plenty more. Currently all of these are usually stored in the extension's main entry point ($IP/extensions/Foo/Foo.php)." (sumanah, 19:02:17)
 * "This creates two problems. First, it's difficult to tell what an extension is going to register without actually enabling the extension. Second, registration currently depends on global state ($wgHooks, $wgSpecialPages, etc.) which we are trying to move away from." (sumanah, 19:02:26)
 * "My proposal is that we store this information in a JSON file (I've provided an example on the RfC), and have MediaWiki read them when loading extensions. We would no longer use the current method of require_once "Foo.php";, but instead $wgEnableExtensions[] = 'foo';, and MediaWiki would take care of the rest." (sumanah, 19:02:34)
 * Today, Kunal (legoktm) wants to know first off, whether this is a good idea :-) and to resolve a "few things that came up on the talk page, including whether it's ok to require extensions to be in $IP/extensions, and if not, how to handle multiple locations, and different ways to cache" (sumanah, 19:02:51)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration#Proposal <-- under the "config" key (legoktm, 19:07:34)
 * AGREED: The directory containing the extensions should be configurable (to accommodate e.g. dev environments or packages), but it's reasonable to require all extensions be in the same directory (sumanah, 19:10:38)
 * Look into [12:10:51 PM]      Either we stop worrying about register_globals and start loving isset( $wgWhatever)  (legoktm, 19:26:47)
 * it seems like we agree that this is not a terrible idea :-) (sumanah, 19:37:58)
 * people seem okay with duplication of trivial info (sumanah, 19:38:53)
 * I'll publish the JSON schema that parent5446 suggested in a few days so it should be clearer what exactly will be possible (sumanah, 19:46:20)

Meeting ended at 19:49:03 UTC.

People present (lines said)

 * sumanah (32)
 * gwicke (26)
 * legoktm (25)
 * RoanKattouw (24)
 * ^d (20)
 * aude (10)
 * Nikerabbit (7)
 * MatmaRex (6)
 * wm-labs-meetbot (4)
 * parent5446 (2)
 * ^demon|away (2)
 * mutante (1)
 * YuviPanda (1)

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Full log
19:00:03 #startmeeting Discussion of Extension Registration | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 19:00:03  Meeting started Fri May 30 19:00:03 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:03  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:03  The meeting name has been set to 'discussion_of_extension_registration___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 19:00:14 #chair sumanah 19:00:14  Current chairs: sumanah 19:00:41 #link https://www.mediawiki.org/wiki/Architecture_meetings/Performance_guidelines_discussion_2014-05-30 19:00:46 #topic Extension registration 19:01:26 I don't see Brion around, and of course it's the weekend for Tim and evening for Mark, but I hope we will still have useful things to say about Kunal's proposal :-) 19:01:30 We're discussing Kunal Mehta's Extension registration RfC. 19:01:33 #link https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration 19:02:04 #info http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076662.html post by Kunal ( legoktm ) about his RfC 19:02:08 To quote Kunal: 19:02:11  sumanah: brion update - he mailed in saying he was sick a couple hours ago. (just a fyi) 19:02:17 #info "Extensions register a lot of things, like classes, hooks, special pages, configuration options, and plenty more. Currently all of these are usually stored in the extension's main entry point ($IP/extensions/Foo/Foo.php)." 19:02:26 #info "This creates two problems. First, it's difficult to tell what an extension is going to register without actually enabling the extension. Second, registration currently depends on global state ($wgHooks, $wgSpecialPages, etc.) which we are trying to move away from." 19:02:34 #info "My proposal is that we store this information in a JSON file (I've provided an example on the RfC), and have MediaWiki read them when loading extensions. We would no longer use the current method of require_once "Foo.php";, but instead $wgEnableExtensions[] = 'foo';, and MediaWiki would take care of the rest." 19:02:44 Thanks YuviPanda 19:02:51 #info Today, Kunal (legoktm) wants to know first off, whether this is a good idea :-) and to resolve a "few things that came up on the talk page, including whether it's ok to require extensions to be in $IP/extensions, and if not, how to handle multiple locations, and different ways to cache" 19:03:41  Re locations 19:03:48  I think nonstandard locations do need to be supported 19:03:53  Lots of people use $IP/../extensions for instance 19:04:18  But I think it's reasonable to configure one extensions directory (defaulting to $IP/extensions) and then require that everything be installed in that one directory 19:04:21 <^d> And some things like OS packages want to put them in *very* different places. 19:04:30  Yeah 19:04:38 <^d> Oooh, +1 to having a single directory per-wiki. 19:04:42  But any sensible scheme will put all the extensions in the same dir 19:04:42 <^d> That makes it easier. 19:04:45  hah nice 19:04:51  That's a good one, you could segregate by wiki that way :) 19:05:26 so we just add a config option to set where your extensions are located, but require that everything is in that one directory? 19:05:35  Basically what I'm saying is if you're a Debian fanboy and you want to have /etc/default/wikimedia/mediawiki-extensions/FlaggedRevs, fine 19:05:57  As long as VisualEditor is then in /etc/default/wikimedia/mediawiki-extensions/VisualEditor, not in /var/www/lolwut/VisualEditor 19:06:03 RoanKattouw, more liken /etc/mediawiki/extensions-enabled/VisualEditor 19:06:06 *likely 19:06:11 <RoanKattouw> Yeah something like that 19:06:33 <^d> Registration as a config variable is hard. Right now the vast majority of extensions end up expecting to be in the global scope for setting config, etc. 19:06:37 similar to apache's sites-enabled 19:06:42 <^d> So the process is require then config. 19:06:49 <^d> How do you config in the proposed setup? 19:07:03 <RoanKattouw> But yeah I think it's sensible to require everything is all in one dir, and in exchange you get to put that dir wherever you like. That shouldn't be too much of a problem, because you can use symlinks. That's what a lot of *-enabled stuff in Debian uses anyway 19:07:14 ^d: like, adding an extension's $wgExtNameFoo options? 19:07:20 <^d> Yep. 19:07:22 <RoanKattouw> Oh, hmm, yeah that's a good question 19:07:34 https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration#Proposal <-- under the "config" key 19:07:51 my understanding is that the info can point to callbacks 19:07:56 which are PHP code 19:07:58 and MediaWiki would just do $conf->set( 'Foo', 'value' ); 19:08:18 <RoanKattouw> legoktm: OK, but what if in LocalSettings.php you want to override those values 19:08:32 ah yeah, that's easier for the simple case 19:08:33 <^d> Yeah, Roan's question is what I was getting at. 19:08:41 <RoanKattouw> Right now it works because require_once("MassMessage.php"); ends up setting $wgAllowGlobalMessages = true; (the default) 19:08:43 <^d> The info.json handles defaults, yeah 19:08:50 <RoanKattouw> And then on the next line I can do = false; and it'll overwrite it 19:09:10 <RoanKattouw> But if I do $wgExtensions[] = 'MassMessage'; $wgAllowGlobalMessages = false; that's not gonna owrk 19:09:21 btw if any of you want this stuff to go into the summary, please #info or #agreed it 19:09:31 mhm, I was going to just have the user set it, and not have MW override it if set, but dantman pointed out that would be a register_globals issue, so I'm not really sure what to do for that. 19:09:54 <^d> Or we could just require 5.4 already and be done with worrying about r_g :p 19:09:59 there could be an explicit call in localsettings to set up all extensions 19:10:13 slightly icky though.. 19:10:22 <RoanKattouw> #agreed The directory containing the extensions should be configurable (to accommodate e.g. dev environments or packages), but it's reasonable to require all extensions be in the same directory 19:10:33 <RoanKattouw> Yeah so the way I see it 19:10:38 #agreed The directory containing the extensions should be configurable (to accommodate e.g. dev environments or packages), but it's reasonable to require all extensions be in the same directory 19:10:46 * sumanah thinks only chairs can do #agreed 19:10:49 whoops 19:10:50 <RoanKattouw> Either we stop worrying about register_globals and start loving isset( $wgWhatever) 19:11:23 <RoanKattouw> Or we do wfEnableExtension( 'MassMessage' ); instead of $wgEnableExtensions[] = 'MassMessage'; 19:11:52 <^d> Or both :) 19:12:10 <^d> I think we should stop worrying about r_g anyway. It's your own damn fault if you turn that shit on. 19:12:30 RoanKattouw: the reason I used an array is so you can put that in the future configuration database 19:12:57 <RoanKattouw> Right 19:13:00 <RoanKattouw> That makes sense 19:13:08 for package installs it would probably be nice to just enable all extensions found in the directory by default 19:13:11 <RoanKattouw> I prefer data-driven stuff too 19:13:26 <^d> gwicke: No. 19:13:28 but let the user override that with an array 19:13:40 <^d> If I clone an extension to start testing I don't want it to immediately start executing. 19:13:45 <^d> That's all dangerous and WordPress-y. 19:13:47 <^d> :) 19:13:53 then you can set the array 19:14:22 I don't like the idea of auto-enabling like that...we just got rid of that for skins too 19:14:31 <MatmaRex> eek, no. what legoktm said 19:14:44 alternatively, you can check out to /extensions-available and do the symlink to /extensions-enabled later 19:14:53 <MatmaRex> (we are getting rid of it, my patches are still pending) 19:15:23 for packages this means that they'll have to do the discovery themselves 19:15:30 which is harder 19:16:08 some explicit 'auto' value could also work 19:16:19 <^d> No they wouldn't. It's configured :) No discovery means nobody has to discover :) 19:16:52 Maybe auto-discovery should be it's own RfC? ;) 19:16:54 that means that installing an extension now involves manual work, or a complex package 19:16:56 :-) 19:16:58 I'd rather not get into it right now :P 19:17:10 <^d> gwicke: As opposed to manual work of installing it now? 19:17:28 ^d, we should do better than that ;) 19:17:52 <^d> Anyway, packaging is getting a little OT I think. 19:17:54 anyway, we could add auto-discovery later 19:18:13 <Nikerabbit> for wikifarms, you definitely want to have a mechanism to conditionally enable extensions 19:18:20 $wgAutoDiscoverExtensions = true; 19:18:34 Nikerabbit, absolutely 19:18:44 I'm just interested in the option of having auto-discovery 19:18:58 <^d> Wizard needs food, badly. 19:20:17 <Nikerabbit> auto-discovery doesn't seem controversial (as long as we do not need to execute unknown code to do it) 19:21:49 I mean having mediawiki optionally discover & enable all extensions in /etc/mediawiki/extensions-enabled/ 19:22:10 anyway, can be done later 19:22:15 <MatmaRex> gwicke: that's already implemented in the installer, if i understand you correctly 19:22:19 gwicke: what about enable based on config? 19:22:37 <MatmaRex> gwicke: it lets you click checkboxes to add require_once lines to generated LocalSettings 19:22:52 for a wikifarm 19:22:59 where we want one extension on x site, not on y 19:23:09 aude, we discussed that already 19:23:12 ah 19:23:46 MatmaRex, in the option I'm interested in you would avoid generating any php or modifying the config 19:23:54 back in a few min. 19:23:56 [12:10:51 PM] <RoanKattouw>	 Either we stop worrying about register_globals and start loving isset( $wgWhatever) <-- is there anything major that would stop us from doing that, provided we announced/socialized it properly? 19:23:59 it's primarily useful for something like deb packages 19:24:45 <MatmaRex> legoktm: assuming we'd want to require php 5.4 to do that, it doesn't have very wide adoption yet. i think this was discussed on wikitech and the conclusion was to try in a couple of months 19:24:53 ok, i see $wgAutoDiscoverExtensions = true; 19:25:00 that should work 19:25:15 MatmaRex: well, I think RoanKattouw meant even if we still support 5.3 19:25:51 <MatmaRex> in that case, probably nothing :) 19:26:47 #info Look into [12:10:51 PM] <RoanKattouw>     Either we stop worrying about register_globals and start loving isset( $wgWhatever) 19:27:32 (back) 19:27:55 another thing that came up on the talk page was some duplication with composer.json files 19:28:09 namely version, url, authors, and autoload 19:29:40 the autoload systems are different, and I think most extensions would still continue to use MediaWiki's autoloader for classes rather than composer's 19:29:57 so it would just be imo trivial info that's being duplicated, are people ok with that? 19:30:43 <Nikerabbit> I would actually like if we could nudge people to more standardized way of doing autoloading 19:31:20 like, psr-4? 19:31:27 +1 19:31:58 sooo much easier if i don't hve to remember to add a class to AutoLoader or some place 19:32:28 and easily understandable 19:33:46 legoktm: so how you doing? :-) anything you want to bring up/get opinions on next? 19:33:59 agreed, but that is also probably off-topic for this RfC :P 19:34:06 agree 19:34:37 well, I was expecting someone to say "this is a terrible idea" but I guess not :D 19:35:17 <^demon|away> The other option is staying on 5.3 *and* not caring about r_g. 19:35:27 <^demon|away> As I said, if you're running with that enabled it's your own damn fault. 19:35:57 yeah, I agree with that 19:36:00 a/win 2 19:37:12 hey parent5446 - http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140530.txt 19:37:58 #info it seems like we agree that this is not a terrible idea :-) 19:38:53 #info people seem okay with duplication of trivial info 19:39:09 anything else to note for the summary? 19:41:10 <Nikerabbit> hmm 19:41:26 I just want it on the record that I'm strongly against unnecessary duplication of information 19:41:54 it is so noted parent5446 19:41:59 <Nikerabbit> many complex extensions set many variables conditionally, even depending on values set by the user 19:41:59 :) thanks 19:42:13 <Nikerabbit> I can't see how json would be able to hand that 19:42:53 Nikerabbit: right, that's why there's a callback if you need to do something in PHP 19:43:19 <Nikerabbit> legoktm: I didn't notice that 19:44:02 it's hidden in the text under the JSON example 19:44:43 I'll publish the JSON schema that parent5446 suggested in a few days so it should be clearer what exactly will be possible 19:46:20 #info I'll publish the JSON schema that parent5446 suggested in a few days so it should be clearer what exactly will be possible 19:46:33 anything else here, legoktm, any next steps anyone else needs to take? 19:47:03 not that I can think of 19:47:09 ok, shall we close it up then? 19:47:42 if no one else has anything to say, sure 19:48:05 * sumanah waits a min. 19:49:03 #endmeeting