Page MenuHomePhabricator

[Story] Find extensions using code directly from Wikibase and provide mechanism with a stable interface
Open, MediumPublic

Description

Find extensions using code directly from Wikibase or other parts of the Wikidata build and provide mechanism with a stable interface instead.

Find extensions using ( include / require / depend on ) code directly from Wikibase or other parts of the Wikidata build and provide a better mechanism. We currently don't provide any stability guarantees. Either define some package public classes that use semver.org to provide stability guarantees or create a component for the functionality.

We should make sure that it is explicitly documented that the extensions in the Wikidata build don't provide any stability guaranties except specific classes declared package public or hooks.

Most functionalities that are currently used can probably be replaced with using the HTTP-API and libraries we already provide.

Event Timeline

hoo raised the priority of this task from to Medium.
hoo updated the task description. (Show Details)
hoo added a project: Wikidata.
hoo added subscribers: hoo, JanZerebecki, Lydia_Pintscher and 2 others.

How do you think we should do this?

One could manually search for use statements beginning with one of the relevant PHP namespaces. This could also be automated with phpcs rules.

The goal here is to make sure that other Mediawiki extensions installed on the cluster use versioned interfaces and declare their dependencies in composer instead of just relying on the classes being there and breaking when we change something. Currently we know that happens, we should find solutions for the cases where it already happens. Also we should actually document what we version with certain stability guarantees and what not. And what is package private and what is public.

In general what we are searching for: use clauses or absolute class names that are not in core nor in the extensions nor in the dependencies declared in the extensions composer.json . All this does not include dependencies included in the composer.json of core, these should be duplicated in the extensions composer.json if they are used in the extension.

More specifically for Wikidata we search for the things from above that are in the build but not in other extensions composer.json .

JanZerebecki renamed this task from Track usage of Wikibase extensions/ components outside of Wikibase/ the Wikidata build to find extensions using code directly from Wikibase and provide mechanism with a stable interface.Jul 24 2015, 4:39 PM
JanZerebecki updated the task description. (Show Details)
JanZerebecki set Security to None.

Am I understanding correctly that this is about the code in Wikibase.git, ie Wikibase Repository, Wikibase Client and Wikibase Lib? If so, please don't refer to that as "Wikibase", since this is a broader term.

Anyway, we've known for some time that we need to provide proper support for code build on top of the Wikibase.git extensions, and that this involves creating proper interfaces, having actual releases and keeping release notes. Now we also have the Wikibase Quality extensions to deal with, this has only become more pressing. We've made some headway by moving code out of Wikibase.git into components that don't have the relevant problems, however the bulk of the issues still remain.

We can document what is and what is not package public. We can also make a 0.5 release if we commit to actually document breaking changes and do proper releases from then on. At least as proper as they can be, with 2 applications and 2 libraries still sitting together in a single git repo.

Am I understanding correctly that this is about the code in Wikibase.git, ie Wikibase Repository, Wikibase Client and Wikibase Lib? If so, please don't refer to that as "Wikibase", since this is a broader term.

Yes, but this is about other components out of our build as well (mostly DM is probably relevant here).

Yes, but this is about other components out of our build as well (mostly DM is probably relevant here).

I don't get it. Which of the described problems do you think are present in the DM component?

Yes, but this is about other components out of our build as well (mostly DM is probably relevant here).

I don't get it. Which of the described problems do you think are present in the DM component?

We're not talking about problems in any of our components here, but about other MediaWiki extension which just use stuff from one of our components without declaring dependencies or anything (they just assume stuff is there and doesn't change).

Other extensions use code from for example the DM component without requiring it via composer.
Please read the last line of the description.

Thanks for clarifying.

Please read the last line of the description.

What line exactly? "Most functionalities that are currently used can probably be replaced with using the HTTP-API and libraries we already provide."? I don't understand what that one is supposed to mean.

I'm quite confused about what exactly this issue is about. "stuff going wrong when people use Wikibase code"? Or one or several more specific things?

What from that sentence is it that you don't understand? Do you have a question?

This task is about people using code from Wikidata.git or mediawiki/vendor.git inapropriately:

  1. People using a package private interface (e.g. something from Wikibase.git), then we change it and as people don't write tests their code breaks in production.
  2. People using a library obtained via composer without depending on it. Their code breaking in production when we upgrade.
Jonas renamed this task from find extensions using code directly from Wikibase and provide mechanism with a stable interface to [Story] Find extensions using code directly from Wikibase and provide mechanism with a stable interface.Nov 2 2015, 3:18 PM

Change 260619 had a related patch set uploaded (by JanZerebecki):
Start docs about public Wikibase APIs and stability guarantees

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

Change 260619 merged by jenkins-bot:
Start docs about public Wikibase APIs and stability guarantees

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

Possibly related: T256959, as in the linked bug might be an subtask.