[09:09:47] Krinkle: it does look like we will have to generate md/php files for config for the foreseeable future... [09:09:52] How do you want to unify them? [09:10:54] I'd still love to see T99268, but that's a rather big project I'm afraid [09:10:54] T99268: RfC: Create a proper command-line runner for MediaWiki maintenance tasks - https://phabricator.wikimedia.org/T99268 [09:11:16] Though the work we are doing on config right now should help a lot. [21:43:52] duesen: It seems inevitable for performance that defaults and most other settings files will be a php file. Converting to an array seems needed in order to make iteration easier (though iteration is expensive, and likely the reason the php implemetnation is still over 10x slower than the status quo; and afaik there's no inherent requirement for iteration in the relevant RFCs; similar for schema validation which doesn't appear there [21:43:52] either). In any event, whatever format we come up with, afaik doc comments can be put in that directly as well, possibly generated. [21:44:02] In that case we wouldn't need the markdown file separately. [21:44:14] it also seems preferable in that would make it possible to reference these in doc blocks [21:45:22] afaik there isn't an IDE friendly way to point to a markdown file, and even if there was, people won't because the intention is to referr to the config variable by name as a concept, not to refer to a paragraph in a markdown file. [21:45:55] Right, but the config setting as a concept is not a PHP language construct. [21:45:56] something like Settings::Sitename could probably be referred to relatively easily [21:46:09] akin to $wgSitename being similarly native [21:46:35] Oh, you mean calss with settings names as static members? Yes, that could work. [21:46:50] or as constants, rather [21:47:55] We need to be able to iterate over all defined vars to juggle scopes for backwarsd compatibility. Schema validation isn't a requirement, just a side effect - we need types and/or merge strategies. doing validations in the test was just nice to have. [21:48:08] I'm way behind on the various tasks and documents, none of which seem to link to each other; but one of the random thins I was wondering is how validation is meant to deal with partial values, e.g. $wgFoo['bar'] = true; If we accept that we cannot validate that until after merging with runtime defaults, then is there any value at all in it being expressed in YAML? [21:48:19] (for non-default settings, e.g. wmf config) [21:49:43] the value is that we know how to do that merging. validation wasn't the primary goal. [21:49:47] It seems the InitialiseSettings/wgConf structure would be the best we can do for a possible YAML file to inject. Though if we accept a minor build step or conversion, we might as well use it as PHP, and then if it comes form the same repo, perhaps even authored in the same PHP file as-is. I'm losing track of what we're solving and what the high-level requirements are vs individual proposals. [21:50:11] the SiteConfiguration class already knows how to do that merging. [21:50:25] it's expressed based on + prefix for values that are meant to be merged. [21:50:48] that's how we do it today in production, since most partial configs already don't use $wgFoo['foo'] assignment syntax [21:50:54] lists and maps need different merging behavior though [21:50:57] we use wgConf instead which is essentially pure data already [21:51:08] they dont need different behaviour today. [21:52:18] I know they do for the stuff ExtensionProcessor does. that's why it has a list of merge strategies for core variables. For other cases, I suppose workarounds are in place. [21:52:52] I was plannign to have a meeting scheduled with you about this a couple of weeks ago... covid interfered. I am now planning to set up meetings for next week. [21:53:18] that's different. ExtensionProcessor is responsible for applying defualts from extension.json retroactively, where it is ambigious whether the default itself is meant to be complete or not. [21:53:35] loading settings doesn't have this issue afaik, it never has. [21:54:23] I'm not sure I understand what you mean by incomplete/partial. That's not really the issue we have been dealing with... [21:54:28] For values in wgConf array that are marked as being a merge instead of assignment, SiteConfiguration does a key merge for associative arrays and list merge for list arrays. The distinction between the two is non-ambigious and even has a php built-in in newer versions. [21:55:04] I havent' looked at every edge case, I could be missing something. I just know it works today and that's interesting. [21:55:54] I'm about to wrap up for today, I think my mental capacity isn't sufficient to do a deep dive on this right now. Does meeting next week work for you? [21:56:08] Yes. [21:56:10] btw one of the worst things to merge is cache config, because it has mixed numeric and string keys [21:56:54] the only ints there are constants, which we could change tomorrow. [21:57:34] seems worth it if it potentiall removes the need for a few thousand lines of code. [21:59:47] true, if we only had that code for this reason... let's talk about it next week.