[18:52:02] in 10 min: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-30 discussion of extension registration RfC here [18:53:59] lilatretikov nice MP share :) [18:54:28] legoktm: I am gonna introduce you & quote what you said in http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076662.html :-) [18:54:30] thanks for writing that [18:54:47] :) [18:55:34] legoktm: what would you like to get out of today's discussion? a specific decision? feedback on anything in particular [18:56:27] well first if its a good idea :P [18:56:40] OK :) [18:56:42] there were a few things that came up on the talk page, including whether its ok to require extensions to be in $IP/extensions, and if not, how to handle multiple locations, and different ways to cache [18:58:08] legoktm: so you want to resolve those questions? sounds good [18:58:59] I'll add that when I intro you [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:10] 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:29] 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:07] *likely [19:06:11] 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] 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] Oh, hmm, yeah that's a good question [19:07:35] 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:57] which are PHP code [19:07:58] and MediaWiki would just do $conf->set( 'Foo', 'value' ); [19:08:18] 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] 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] And then on the next line I can do = false; and it'll overwrite it [19:09:09] 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:10:00] there could be an explicit call in localsettings to set up all extensions [19:10:14] slightly icky though.. [19:10:21] #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] 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] Either we stop worrying about register_globals and start loving isset( $wgWhatever) [19:11:23] 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] Right [19:13:00] 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] I prefer data-driven stuff too [19:13:27] <^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:23] I don't like the idea of auto-enabling like that...we just got rid of that for skins too [19:14:31] 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] (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:12] 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] auto-discovery doesn't seem controversial (as long as we do not need to execute unknown code to do it) [19:21:50] I mean having mediawiki optionally discover & enable all extensions in /etc/mediawiki/extensions-enabled/ [19:22:10] anyway, can be done later [19:22:14] 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] 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] 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] 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] in that case, probably nothing :) [19:26:47] #info Look into [12:10:51 PM] 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] 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:27] and easily understandable [19:33:46] legoktm: so how you doing? :-) anything you want to bring up/get opinions on next? [19:34:00] 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:58] 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] hmm [19:41:27] 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] many complex extensions set many variables conditionally, even depending on values set by the user [19:41:59] :) thanks [19:42:13] 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] 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:02] #endmeeting [19:49:03] Meeting ended Fri May 30 19:49:03 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [19:49:03] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.html [19:49:03] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.txt [19:49:03] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.wiki [19:49:04] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.log.html [19:49:07] Thanks all [19:51:00] thanks! and thank you sumanah for setting it up :) [19:51:06] :) [19:53:03] Ack, shame I had a dentist appointment. [20:51:14] !logs [20:53:34] Hi, Amgine. [20:53:37] https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-30-19.00.log.html [20:54:27] Hmm, I guess https://meta.wikimedia.org/wiki/IRC_office_hours#Office_hour_logs doesn't get updated automatically [21:06:07] Thanks! [21:06:28] You're welcome! [21:06:36] How come you're not in New York? :-( [21:12:46] Emufarmers: because I have no interest in going to New York? but, more importantly, I don't know what's going on there. [21:13:17] http://wikiconferenceusa.org/wiki/Main_Page [21:13:28] [21:13:56] oh, gawd. People. [21:24:06] Amgine: what did I do? :/ [21:24:20] made an illogical argument. [22:05:03] That's been a lot of reading, and I'm not entirely sure I understood it all. What I *think* the proposal does is rearrange the deck chairs a bit, to make some of the configuration and content less php-specific.