Change 616161 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/ArticlePlaceholder@master] Add WikibaseClient as dependency of this extension

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

Concluding from the discussion on the patch. It appears that there isn't an elegant way to achieve this. After a discussion with @Lucas_Werkmeister_WMDE we propose to mark this task as declined. However, we keep this open for now, in case someone else has an elegant way to resolve it.

In T258822#6373399, @ItamarWMDE wrote:

Concluding from the discussion on the patch. It appears that there isn't an elegant way to achieve this. After a discussion with @Lucas_Werkmeister_WMDE we propose to mark this task as declined. However, we keep this open for now, in case someone else has an elegant way to resolve it.

Why would you decline a bug that is valid?

I could understand marking it stalled, dependant on another bug being filed and fixed (ie something to support Wikibase's non standard file heirarchy), but it's definitely not invalid.

If an extension is unable to declare a dependancy because of MW's expecttions, that is a bug. But said bug needs to be filed, not just left as comments on a gerrit task...

I agree with @Reedy this is hard to do but it should not be declined (maybe moved to stalled, etc.)

In T258822#6373587, @Reedy wrote:

In T258822#6373399, @ItamarWMDE wrote:

Concluding from the discussion on the patch. It appears that there isn't an elegant way to achieve this. After a discussion with @Lucas_Werkmeister_WMDE we propose to mark this task as declined. However, we keep this open for now, in case someone else has an elegant way to resolve it.

Why would you decline a bug that is valid?

Because Declined is not the same as Invalid? I’m not saying the bug isn’t valid, but we may still decline to resolve it.

I could understand marking it stalled, dependant on another bug being filed and fixed (ie something to support Wikibase's non standard file heirarchy), but it's definitely not invalid.

How, then, would you support Wikibase’s file hierarchy in MediaWiki core?

I can think of two ways:

1. Hard-code in MediaWiki core where Wikibase’s extension JSON files are, so that the installer can load them correctly.

2. Extend the extension JSON syntax, and require extensions depending on Wikibase to write something like this:

"requires": {
  "extensions": {
    "WikibaseClient": {
      "baseName": "Wikibase",
      "jsonName": "extension-client.json",
      "version": "*"
    }
  }
},

Both seem so terrible to me that I’d rather decline this task than implement either of them. If you have a better idea, let us know, that’s why we left this task open for a bit. But my impression is that this task is not doable – neither core nor other extensions should have special knowledge of Wikibase paths, but those paths have to be somewhere if the installer is supposed to be able to locate Wikibase automatically.

Of course the problem here is effectively that Wikibase is doing something non standard/not supported. So you could question if it should be doing that...

How does Wikibase even get loaded properly for CI with the non standard paths? Does -with-extensions do something more recursively? Or does it not get loaded at all?

If it does something more recursively, it seems to be that it could be useful if the installer doesn't try and load all dependancies immediately, but instead wait till all extensions that are going to be loaded as a matter of course get loaded, and then see which are still needed, try and load them.. And if it still doesn't work, then die?

As per my original point in this comment... If this is something "we" want to support in some way, some time and thought should be put into it... If not, Wikibase should potentailly stop being the odd one out here and do something more standard (which probably ends up with multiple extensions again).

Else, potentially something more like T182472: Allow extension registration to suggest optional extension/skin or MediaWiki version where it's not a hard dependancy... but at least has it decorated in a structured (ish) fashion rather than having to dig through errors/docs etc to work out what's going on

Anything has got to be better than the installer pretending it's installing the extension fine, when actually mass amounts of dependancies are actually missing

In T258822#6373759, @Lucas_Werkmeister_WMDE wrote:

In T258822#6373587, @Reedy wrote:

In T258822#6373399, @ItamarWMDE wrote:

Concluding from the discussion on the patch. It appears that there isn't an elegant way to achieve this. After a discussion with @Lucas_Werkmeister_WMDE we propose to mark this task as declined. However, we keep this open for now, in case someone else has an elegant way to resolve it.

Why would you decline a bug that is valid?

Because Declined is not the same as Invalid? I’m not saying the bug isn’t valid, but we may still decline to resolve it.

I could understand marking it stalled, dependant on another bug being filed and fixed (ie something to support Wikibase's non standard file heirarchy), but it's definitely not invalid.

How, then, would you support Wikibase’s file hierarchy in MediaWiki core?

I can think of two ways:

1. Hard-code in MediaWiki core where Wikibase’s extension JSON files are, so that the installer can load them correctly.

2. Extend the extension JSON syntax, and require extensions depending on Wikibase to write something like this:

"requires": {
  "extensions": {
    "WikibaseClient": {
      "baseName": "Wikibase",
      "jsonName": "extension-client.json",
      "version": "*"
    }
  }
},

Both seem so terrible to me that I’d rather decline this task than implement either of them. If you have a better idea, let us know, that’s why we left this task open for a bit. But my impression is that this task is not doable – neither core nor other extensions should have special knowledge of Wikibase paths, but those paths have to be somewhere if the installer is supposed to be able to locate Wikibase automatically.

Actually I think there's a rather easier path to go to and it doesn't involve splitting Wikibase git repo either. Installer.php currently loads the files and check for their existence. The whole logic seems wrong to me, it should load extensions from the extension registry or check if they are in the queue and check it only based on name. If it can't find the extension in extension registry, then It should fall back to loading it directly from file and its current logic.

In my personal opinion what Wikibase is doing is not "non-standard", it's just different (Wikibase is unique in so many ways, this the least of the differences) but I think the logic of loading extensions should be hidden and abstracted to ExtensionRegistry class which its whole point is to abstract this away.

How does Wikibase even get loaded properly for CI with the non standard paths? Does -with-extensions do something more recursively? Or does it not get loaded at all?

It looks for Wikibase.php, that file loads extension json files.

In T258822#6374334, @Ladsgroup wrote:

How does Wikibase even get loaded properly for CI with the non standard paths? Does -with-extensions do something more recursively? Or does it not get loaded at all?

It looks for Wikibase.php, that file loads extension json files.

Right. So as I said, it should check unresolved dependancies at the end of loading everything else, and then error if it's still unmet, rather than apparently immediately erroring just because it can't find the extension.json in the "right" place

In T258822#6373807, @Reedy wrote:

..., it seems to be that it could be useful if the installer doesn't try and load all dependancies immediately, but instead wait till all extensions that are going to be loaded as a matter of course get loaded, and then see which are still needed, try and load them.. And if it still doesn't work, then die?

That sounds good to me (sorry I missed this part of your comment). I can try to see if I can make a patch for this.

Okay, this is blocked on T258822: Wikibase extensions do not declare extension.json dependency on Wikibase getting done, once that's done we can pick this up.

Change #1205175 had a related patch set uploaded (by Hashar; author: Hashar):

[mediawiki/core@master] installer: support WikibaseClient and WikibaseRepository

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