[17:44:46] [[Tech]]; Paraenti; /* How to lure a fish into a bait */ new section; https://meta.wikimedia.org/w/index.php?diff=22427091&oldid=22419764&rcid=20857793 [17:48:13] [[Tech]]; Majavah; Undo revision 22427091 by [[Special:Contributions/Paraenti|Paraenti]] ([[User talk:Paraenti|talk]]) test edit; https://meta.wikimedia.org/w/index.php?diff=22427198&oldid=22427091&rcid=20857906 [18:48:14] [[Tech]]; Paraenti; Replaced content with "{{bluehive.com}}"; https://meta.wikimedia.org/w/index.php?diff=22427596&oldid=22427198&rcid=20858464 [18:48:34] [[Tech]]; Majavah; Undo revision 22427596 by [[Special:Contributions/Paraenti|Paraenti]] ([[User talk:Paraenti|talk]]); https://meta.wikimedia.org/w/index.php?diff=22427597&oldid=22427596&rcid=20858468 [20:11:46] legoktm[m]: thanks for your feedback. The reason for grouping in arrays is to provide a replacement for global variable prefixes. If we are doing away with global variable usage for settings, we need some kind of replacement. [20:13:25] legoktm[m]: SettingsBuilder currently only supports one prefix for globals. IF we want to consolidate the config handling code with ExtensionRegistry, we need to either add support for multiple prefixes, or deprecate prefixes in favor of some other mechanism. [20:13:32] you want to get rid of "wg"? [20:13:44] I want to get rid of globals. So yes. [20:13:47] or do you mean custom prefixes that aren't "wg"? [20:14:02] First custom, than all prefixes. [20:15:05] Instead of having a global scope of variables partitioned by prefix, I want a set or hierarchy of Config objects backed by arrays. [20:16:16] I should clarify, my dislike of PHP arrays is that they're not the easiest to write in LocalSettings.php, but if people aren't writing config in PHP anymore that concern goes away [20:16:47] Re non-php-experts setting values in LocalSettings.php: in the BrightAndShinyFuture, there is no LocalSettings.php, there is LocalSettings.yaml. Nested structures in YAML are much nicer than key prefixes [20:17:05] Yes, exactly [20:17:08] :D [20:17:30] and yeah, "wg" is only needed as a disambiguator for PHP globals [20:17:55] it shouldn't be needed in any other case, which is why the \Config interface dropped it [20:18:07] And if we no longer export config to globals, there is no good way to keep support for custom prefixes. [20:19:11] I think deprecating custom prefixes should be straightforward, it's very rarely used I think [20:19:27] Not super rare, but not used a lot, yes. [20:19:51] But some kind of namespacing would be good to have. Entirely optional of course. [20:19:56] https://codesearch-beta.wmcloud.org/search/?files=%28extension%7Cskin%29.json%24&i=nope&q=config_prefix [20:20:07] half of which is BlueSpice [20:21:37] There is quite a few using the old way, too: https://codesearch-beta.wmcloud.org/search/?files=%28extension%7Cskin%29.json%24&i=nope&q=%22_prefix%22%3A [20:23:10] By the way, I have been thinking about your concept of "an API for LocalSettings". I'm thinking about creating a class called Settings with a bunch of static methods, such as loadExtension( $name ) and loadSettings( $path ). It'S prettier than $wgSettings->loadFile( $path ); [20:24:06] I wonder why people use such weird prefixes [20:24:10] We could also have Settings::set( 'Foo', 'bar' ). And we could support path syntax in that, as in Settings::set( 'Bla.Blubb.Bra', 'bar' ) [20:25:03] what would that be used for in our dream LocalSettings.php-less world? [20:27:42] That would be used in LocalSettings.php :) The idea is not to remove support for LocalSettings.php entirely. We'd want to keep it for complex setups that need dynamic config. But "non-experts" could just use LocalSettings.yaml in 99% of their use cases [20:28:23] The installer would generate a LocalSettings.yaml. But if you really wanted to, you could still create a LocalSettings.php to do whatever magic [20:28:47] We'll probably never get rid of code in config entirely. I'd be happy if we can get rid of 90%. [20:29:10] fair enough [20:30:17] having path support in Settings::set() would be nice [20:30:35] not sure though what advantage that is over just plain variables or having it return an array [20:30:37] The thing I'd want to take away entirely is setting global variables in LocalSettings.php. We may allow setting variables, but they would not be in the global scope. And ideally, everythign would be done via Settings::xyz methods. [20:31:10] would you try to stop loading it in file scope? [20:31:28] yes [20:32:59] The only advantage of Settings:set() would be the path syntax, and convenience/consistency, e.g. for the path syntax. There would also be Settings::get(), etc. This would make it easier to mix and match programmatic setting of config with loading config from files. [20:34:54] yeah [20:35:15] it would be nice if we didn't need the autoloader for LocalSettings [20:35:39] but I'm not sure that's practical, since people are probably going to reach for different PHP classes anyways [20:37:10] I feel like we shouldn't need it. Or at least make it something that has to be enabled explicitly. Like Settings::initializedAutoLoader() or something. [20:37:41] I can't think of a legitimate use case. Maybe perhaps defining constants for use in LocalSettings? [20:38:28] But if it's really needed, we shouldn't have to make it happen magically. People who do need it can just add some magic incantation to their LocalSettings.php [20:39:54] yeah, agreed [20:40:13] that would mean though that Settings needs to be self-contained [20:43:34] Settings will need access to some core stuff. In particular, everything we are putting into the Settings namespace. [20:44:35] Se yes, *some* autoloading will have to be available. Maybe even all of core's. I was really thinking of autoloading of extension classes... [20:46:35] nothing from extensions should be available and ever since extension.json, it hasn't been [20:46:51] because extensions only get loaded after LocalSettings.php [20:53:33] oh right - was was confused because of the recent issue with SMW. But that was because the way they use composer. [21:29:43] duesen: "I can't think of a legitimate use case." for autoloader in LocalSettings? What about registering hook handlers? Things like https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/wikitech.php#L107