Change Details

**Goal of this task is to solicit opinions on storing MW config in YAML instead of JSON** The overall goal of the SettingsLoader project is to be able to load the majority of our configuration from completely static sources (JSON files, YAML files, PHP arrays, etc) instead of executing PHP code currently residing in CommonSettings.php In the current prototype we define settings files which can contain config key definitions (in the form of json schema for each key) and the config values as a simple map. Example: ``` config-schema: GroupPermissions: type: object additionalProperties: type: object additionalProperties: type: boolean mergeStrategy: array_plus_2d default: sysop: edit: true description: |- This is the description of the config variable. ``` In this approach wiki configuration is split into layers of settings files, like 'default', 'common', 'group1', 'enwiki' with every further layer overriding (or merging according to the merge strategy) the more specific values into already existing configs. The system is very similar to extension loading. The result is then cached in an injectable cache (APCu at this point of thinking), so if the config files are only re-read again if they change. Loading of the settings files is controlled using a SettingsBuilder class and can be freely interleaved with current PHP variable setting. We think that the primary format for the settings files should be YAML. Benefits of YAML: - Better readability. Compare [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/737830/7/includes/defaults.json | JSON ]] with [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/738491/2/out.yaml | YAML ]] - Support for comments. In a static config system we need some place to store code comments, like a ticket number for why the setting was changed, etc. - Support for multiline string blocks - for config definitions, currently residing in DefaultSettings.php we need a place to write the documentation for every config key. Currently the documentation is in PHPDoc blocks, in a new system the natural place for that is 'description' key in the schema, but the docs have to be multiline to be readable. - Better integration with helm. YAML is the preferred format in Helm charts, and at least some of our settings files will probably be generated using Helm from values.yaml Disadvantages of YAML - Slower parsing? This should not matter to us since the parse result is cached, and only reloaded on redeploy. - ...??? Please tell us your opinions on the YAML vs JSON question. We will be holding additional consultations on the project overall, but we would like to know your opinions on this specific question earlier cause we think it will likely be a point of contention and want to address it before we have the complete prototype to present.

**Goal of this task is to solicit opinions on storing MW config in YAML instead of JSON** TLDR: we want to store DefaultSettings.php to YAML. Depending on the feedback, we might consider storing more things in YAML. The overall goal of the SettingsLoader project is to be able to load the majority of our configuration from completely static sources (JSON files, YAML files, PHP arrays, etc) instead of executing PHP code currently residing in CommonSettings.php In the current prototype we define settings files which can contain config key definitions (in the form of json schema for each key) and the config values as a simple map. Example: ``` config-schema: GroupPermissions: type: object additionalProperties: type: object additionalProperties: type: boolean mergeStrategy: array_plus_2d default: sysop: edit: true description: |- This is the description of the config variable. ``` In this approach wiki configuration is split into layers of settings files, like 'default', 'common', 'group1', 'enwiki' with every further layer overriding (or merging according to the merge strategy) the more specific values into already existing configs. The system is very similar to extension loading. The result is then cached in an injectable cache (APCu at this point of thinking), so if the config files are only re-read again if they change. Loading of the settings files is controlled using a SettingsBuilder class and can be freely interleaved with current PHP variable setting. We think that the primary format for the settings files should be YAML. Benefits of YAML: - Better readability. Compare [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/737830/7/includes/defaults.json | JSON ]] with [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/738491/2/out.yaml | YAML ]] - Support for comments. In a static config system we need some place to store code comments, like a ticket number for why the setting was changed, etc. - Support for multiline string blocks - for config definitions, currently residing in DefaultSettings.php we need a place to write the documentation for every config key. Currently the documentation is in PHPDoc blocks, in a new system the natural place for that is 'description' key in the schema, but the docs have to be multiline to be readable. - Better integration with helm. YAML is the preferred format in Helm charts, and at least some of our settings files will probably be generated using Helm from values.yaml Disadvantages of YAML - Slower parsing? This should not matter to us since the in configs the parse result is always cached, and only reloaded when config was changed. - ...??? Please tell us your opinions on the YAML vs JSON question. We will be holding additional consultations on the project overall, but we would like to know your opinions on this specific question earlier cause we think it will likely be a point of contention and want to address it before we have the complete prototype to present.

**Goal of this task is to solicit opinions on storing MW config in YAML instead of JSON** TLDR: we want to store DefaultSettings.php to YAML. Depending on the feedback, we might consider storing more things in YAML. The overall goal of the SettingsLoader project is to be able to load the majority of our configuration from completely static sources (JSON files, YAML files, PHP arrays, etc) instead of executing PHP code currently residing in CommonSettings.php In the current prototype we define settings files which can contain config key definitions (in the form of json schema for each key) and the config values as a simple map. Example: ``` config-schema: GroupPermissions: type: object additionalProperties: type: object additionalProperties: type: boolean mergeStrategy: array_plus_2d default: sysop: edit: true description: |- This is the description of the config variable. ``` In this approach wiki configuration is split into layers of settings files, like 'default', 'common', 'group1', 'enwiki' with every further layer overriding (or merging according to the merge strategy) the more specific values into already existing configs. The system is very similar to extension loading. The result is then cached in an injectable cache (APCu at this point of thinking), so if the config files are only re-read again if they change. Loading of the settings files is controlled using a SettingsBuilder class and can be freely interleaved with current PHP variable setting. We think that the primary format for the settings files should be YAML. Benefits of YAML: - Better readability. Compare [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/737830/7/includes/defaults.json | JSON ]] with [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/738491/2/out.yaml | YAML ]] - Support for comments. In a static config system we need some place to store code comments, like a ticket number for why the setting was changed, etc. - Support for multiline string blocks - for config definitions, currently residing in DefaultSettings.php we need a place to write the documentation for every config key. Currently the documentation is in PHPDoc blocks, in a new system the natural place for that is 'description' key in the schema, but the docs have to be multiline to be readable. - Better integration with helm. YAML is the preferred format in Helm charts, and at least some of our settings files will probably be generated using Helm from values.yaml Disadvantages of YAML - Slower parsing? This should not matter to us since the in configs the parse result is always cached, and only reloaded on redeploywhen config was changed. - ...??? Please tell us your opinions on the YAML vs JSON question. We will be holding additional consultations on the project overall, but we would like to know your opinions on this specific question earlier cause we think it will likely be a point of contention and want to address it before we have the complete prototype to present.