Dependencies, Composer, and more

Semantic MediaWiki and its dependencies

Over the years, the Semantic MediaWiki code base has collected a vast amount of interdependent classes which are hard to read (in a literal sense) or maintain and to improve the situation in the long run Semantic MediaWiki 1.9.0 started to separate classes by responsibility. It further became apparent that specific functionality part of its core are better placed outside of its code base to entangle dependencies and make them more visible and distinguishable.

Placing dependencies outside of the core helps (in some not in all cases) to avoid falling into the trap of a kitchen sink (where everything seems possible or can be conceived of).

Some developers are convinced that maintainability is the result of strong coupling, placing everything in one folder with testing being a possible by-product of a software process but experience by other FOSS projects have shown that such conviction rarely holds true over an extended maintenance cycle therefore Semantic MediaWiki tries to follow best practice where it seems feasible (and possible) including split classes by responsibility, new functionality are to be accompanied by tests (which includes unit and functional tests), PSR-4 support.

Decreasing or isolating Semantic MediaWiki's reliance on MediaWiki (and hereby its software components) is another objective as recent MW releases are causing constant irritations with established tests and functionality and amounts for developer effort (by volunteers) to compensate (analyze, test, re-route existing functionality etc.) for those encountered inefficiencies.

Composer for what?

In order to manage dependencies and free users from the burden to collect single software packages and bundle them in a fashion that makes them work together, Composer as dependency manager has been the choice for many FOSS projects to handle php related software packaging.

Semantic MediaWiki has selected Composer because of its prominent position and acceptance within other (non-WMF/MW related) projects to ensure it does not increase its dependencies on MediaWiki specific technologies or solutions.

Not exclusively but as a by-product, Semantic MediaWiki's semver compliance allows bugfixes to be roll-out in an instant when users rely on a tilde (~2.3 means >=2.3.0,<3.0.0) and caret (^2.3 means >=2.3.0,<3.0.0) versioning constraint with Composer.

With the support for PSR-4, classes are automatically registered and loaded by Composer which decreases the effort for developers to update (or even forget) class registration and the test environment is setup with minimal effort for maintenance and personal interaction (no manual intervention and update of git subversion lists or commands are necessary etc.).

Can I use git, or what if Composer isn't available?

git can be used independently but a user has to ensure that dependencies are up-to-date otherwise changed or added dependencies can contain outdated references (caused by a circumvented Composer use where it normally would detect and load changed dependencies).

If Composer cannot be used then the tarball download or tarball building service are viable alternatives.

What about MW's extension.json?

Internal evaluation has shown that maintaining extension.json does not add any value to SMW extensions and in fact it increases reliance and maintenance burden for a solely MW specific mechanism.

Besides the maintenance issue, extension.json posses issue in terms of transactional and functional definitions (i.e loading messages via a JSON file is a good use yet specifying hooks via JSON seems counterintuitive to what the JSON format was intended for, PHP classes/hooks are not string entities etc.) of classes.

Dependencies, Composer, and more

See also[edit]