19:00:03 <sumanah> #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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:03 <wm-labs-meetbot> 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 <sumanah> #chair sumanah
19:00:14 <wm-labs-meetbot> Current chairs: sumanah
19:00:41 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/Performance_guidelines_discussion_2014-05-30
19:00:46 <sumanah> #topic Extension registration
19:01:26 <sumanah> 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 <sumanah> We're discussing Kunal Mehta's Extension registration RfC.
19:01:33 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration
19:02:04 <sumanah> #info http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076662.html post by Kunal ( legoktm ) about his RfC
19:02:08 <sumanah> To quote Kunal:
19:02:11 <YuviPanda> sumanah: brion update - he mailed in saying he was sick a couple hours ago. (just a fyi)
19:02:17 <sumanah> #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 <sumanah> #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 <sumanah> #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 <sumanah> Thanks YuviPanda
19:02:51 <sumanah> #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 <RoanKattouw> Re locations
19:03:48 <RoanKattouw> I think nonstandard locations do need to be supported
19:03:53 <RoanKattouw> Lots of people use $IP/../extensions for instance
19:04:18 <RoanKattouw> 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 <RoanKattouw> Yeah
19:04:38 <^d> Oooh, +1 to having a single directory per-wiki.
19:04:42 <RoanKattouw> But any sensible scheme will put all the extensions in the same dir
19:04:42 <^d> That makes it easier.
19:04:45 <RoanKattouw> hah nice
19:04:51 <RoanKattouw> That's a good one, you could segregate by wiki that way :)
19:05:26 <legoktm> 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 <RoanKattouw> 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 <RoanKattouw> As long as VisualEditor is then in /etc/default/wikimedia/mediawiki-extensions/VisualEditor , not in /var/www/lolwut/VisualEditor
19:06:03 <gwicke> RoanKattouw, more liken /etc/mediawiki/extensions-enabled/VisualEditor
19:06:06 <gwicke> *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 <gwicke> 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 <legoktm> ^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 <legoktm> https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration#Proposal <-- under the "config" key
19:07:51 <gwicke> my understanding is that the info can point to callbacks
19:07:56 <gwicke> which are PHP code
19:07:58 <legoktm> 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 <gwicke> 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 <sumanah> btw if any of you want this stuff to go into the summary, please #info or #agreed it
19:09:31 <legoktm> 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 <gwicke> there could be an explicit call in localsettings to set up all extensions
19:10:13 <gwicke> 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 <sumanah> #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 <sumanah> 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 <legoktm> 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 <gwicke> 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 <gwicke> 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 <gwicke> then you can set the array
19:14:22 <legoktm> 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 <gwicke> 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 <gwicke> for packages this means that they'll have to do the discovery themselves
19:15:30 <gwicke> which is harder
19:16:08 <gwicke> 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 <legoktm> Maybe auto-discovery should be it's own RfC? ;)
19:16:54 <gwicke> that means that installing an extension now involves manual work, or a complex package
19:16:56 <sumanah> :-)
19:16:58 <legoktm> 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 <gwicke> ^d, we should do better than that ;)
19:17:52 <^d> Anyway, packaging is getting a little OT I think.
19:17:54 <gwicke> 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 <gwicke> $wgAutoDiscoverExtensions = true;
19:18:34 <gwicke> Nikerabbit, absolutely
19:18:44 <gwicke> 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 <gwicke> I mean having mediawiki optionally discover & enable all extensions in /etc/mediawiki/extensions-enabled/
19:22:10 <gwicke> 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 <aude> 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 <aude> for a wikifarm
19:22:59 <aude> where we want one extension on x site, not on y
19:23:09 <gwicke> aude, we discussed that already
19:23:12 <aude> ah
19:23:46 <gwicke> MatmaRex, in the option I'm interested in you would avoid generating any php or modifying the config
19:23:54 <sumanah> back in a few min.
19:23:56 <legoktm> [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 <gwicke> 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 <aude> ok, i see $wgAutoDiscoverExtensions = true;
19:25:00 <aude> that should work
19:25:15 <legoktm> 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 <legoktm> #info Look into [12:10:51 PM]  <RoanKattouw>     Either we stop worrying about register_globals and start loving isset( $wgWhatever)
19:27:32 <sumanah> (back)
19:27:55 <legoktm> another thing that came up on the talk page was some duplication with composer.json files
19:28:09 <legoktm> namely version, url, authors, and autoload
19:29:40 <legoktm> 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 <legoktm> 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 <legoktm> like, psr-4?
19:31:27 <aude> +1
19:31:58 <aude> sooo much easier if i don't hve to remember to add a class to AutoLoader or some place
19:32:28 <aude> and easily understandable
19:33:46 <sumanah> legoktm: so how you doing? :-) anything you want to bring up/get opinions on next?
19:33:59 <legoktm> agreed, but that is also probably off-topic for this RfC :P
19:34:06 <aude> agree
19:34:37 <legoktm> 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 <legoktm> yeah, I agree with that
19:36:00 <mutante> a/win 2
19:37:12 <sumanah> hey parent5446 - http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140530.txt
19:37:58 <sumanah> #info it seems like we agree that this is not a terrible idea :-)
19:38:53 <sumanah> #info people seem okay with duplication of trivial info
19:39:09 <sumanah> anything else to note for the summary?
19:41:10 <Nikerabbit> hmm
19:41:26 <parent5446> I just want it on the record that I'm strongly against unnecessary duplication of information
19:41:54 <sumanah> 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 <parent5446> :) thanks
19:42:13 <Nikerabbit> I can't see how json would be able to hand that
19:42:53 <legoktm> 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 <legoktm> it's hidden in the text under the JSON example
19:44:43 <legoktm> 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 <sumanah> #info <legoktm> 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 <sumanah> anything else here, legoktm, any next steps anyone else needs to take?
19:47:03 <legoktm> not that I can think of
19:47:09 <sumanah> ok, shall we close it up then?
19:47:42 <legoktm> if no one else has anything to say, sure
19:48:05 * sumanah waits a min.
19:49:03 <sumanah> #endmeeting