Page MenuHomePhabricator

Ensure the schema path is relative to the extension directory (not extensions)
Closed, DeclinedPublic2 Estimated Story Points

Description

As developer using CC I want the schema definitions to be relative to the root directory of my extension. This is helps the code be more conventional and makes the the definition not depend on the extension name.

Context
The current extension prototype assumes schema paths defined in the consumers extension.json are relative to the extensions directory rather than the extension root directory. This task is to re-work the current SchemaResolver logic an allow to define schemas relative to the consumer extension directory. For instance, current schema defined as MyExtension/src/Schemas/schema.json should be defined and loaded as src/Schemas/schema.json.

CommunityConfigurationExample has an example of this path definition that can be used for testing, see source.

Acceptance criteria

  • Schema path definition for CC consumers is relative to the extension directory
  • CommunityConfigurationExample is updated accordingly

Event Timeline

KStoller-WMF moved this task from Inbox to Up Next on the Growth-Team board.
KStoller-WMF set the point value for this task to 2.Jan 9 2024, 4:31 PM

Change 994729 had a related patch set uploaded (by Urbanecm; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Add schema resolver logic to make schema definitions relative to extension directory

https://gerrit.wikimedia.org/r/994729

Looking into how "attributes" are extracted from extension.json file I don't see an easy way to define a basePath for all provider schemas (similar to what ResourceLoader does with file paths). The reason is the attributes extraction is agnostic to the extension providing them as far as I can see. So far these are some alternative options: 1) go back to modifying the extension.json schema and have a custom extraction mechanism 2) define the schemas base path for each provider, which defeats most of the goal of the task 3) List target providers under the basePath definition. 4) Modify ExtensionRegistry to keep track of the source of the attributes. Any ideas @Urbanecm_WMF ?

Actually it seems the Hooks attribute extraction does something like what we need here adding an extensionPath to the resolved information. Would it make sense to have some mechanism to optionally aggregate this piece of data to the resolved attributes? Or this seems to specific of our needs here? cc @daniel

Sorry to say that when the work is in progress, but... in the past, we did talk about using a shared place for all configuration schemas, to enable Growth to review major changes and be able to advice on the feature's usage. If this is something we want to do, then this would reform this task's scope significantly. @Sgs, do you have an opinion on this?

Sorry to say that when the work is in progress, but... in the past, we did talk about using a shared place for all configuration schemas, to enable Growth to review major changes and be able to advice on the feature's usage. If this is something we want to do, then this would reform this task's scope significantly. @Sgs, do you have an opinion on this?

What would be such shared place, a repository, a directory in MW?

I'm concerned about adding more work in the daily Growth duties and become a potential bottleneck for other teams. "Review major changes" in a schema would probably mean a migration which I expect to have a documentation for. I'm not sure a "Code review" approach is the most suitable to "be able to advice on the feature's usage". I think with proper documentation and making Growth engineers reachable through standard communication channels that would be covered.

Could you give a concrete example of a schema change that you would consider a -1/-2? I think we should start working on parts of T349039; one thing that we can capture there is the outcome of this discussion.

Sgs changed the task status from Open to Stalled.Feb 28 2024, 5:07 PM
Sgs removed Cyndymediawiksim as the assignee of this task.
Sgs added a subscriber: Cyndymediawiksim.

This is pending the outcome of T351232 research/decision. Let's leave it stalled until we have a clearer idea on how are we gonna "register" schemas.

This is pending the outcome of T351232 research/decision. Let's leave it stalled until we have a clearer idea on how are we gonna "register" schemas.

FYI, see the WIP patches in T358799.

Based on a discussion with @Sgs. This will be obsoleted by finishing T358799: CommunityConfiguration: Switch to generating schemas from PHP classes rather than committing them as JSON files directly, which would help us to avoid loading schemas directly from the filesystem. Instead, we would depend on the PHP classes – something MediaWiki's autoloader is well-equipped to handle.

Change #994729 abandoned by Urbanecm:

[mediawiki/extensions/CommunityConfiguration@master] Add schema resolver logic to make schema definitions relative to extension directory

Reason:

task was declined

https://gerrit.wikimedia.org/r/994729