Requests for comment/Proper command-line runner for maintenance tasks

Your comments here.

Background
MediaWiki maintenance scripts are used for tons of things, but writing them is annoying, and finding the right one to use is kind of impossible.

Logs from 2015 IRC discussion.

Problem
is a mess: it contains over 150 PHP scripts, which range from essential to obscure or obsolete, with no sign-posts to guide the user to the one they need or to facilitate discovery. Were the README and online documentation comprehensive and current, they would still not be an adequate substitute for a good command-line interface.

It's also a problem on a technical level as well. Because maintenance scripts are their own entry point, every script has to copy in the same boilerplate:

For extensions, they have to check whether the extension is even installed, since wiki farms will often have extensions checked out, but not necessarily enabled on the specific wiki.

Proposal
This RFC proposes to introduce a top-level command-line entry-point to MediaWiki which would provide access to individual maintenance tasks via subcommands. If the user does not specify a subcommand, a listing of the most commonly-used maintenance script should be enumerated, with appropriate in-line help, and presented to the user along with a tip on how to access detailed help for a particular subcommand.

This proposal could be implemented simply and without breaking backward-compatibility. The maintenance/ file hierarchy will stay and users will continue to be able to execute maintenance scripts directly. (This guarantee should not extend to future maintenance tasks, as a way of gradually driving users to adopt the top-level entry-point.) And eventually the old entry points will be removed.

The scaffolding for this design is the existing Maintenance class hierarchy, which already does most of the heavy lifting we need.

Structure
The classes that power maintenance scripts will be moved out of the entrypoints, probably into. This will probably happen gradually. The entry points will continue to function, but eventually will emit deprecation notices.

They'll still extend the Maintenance class, and continue to be included in the autoloader.

Registry
We'll maintain a registry of maintenance scripts.

I'm thinking that scripts can be classified into two types based on audience: sysadmins and developers. For example, createAndPromote.php is for sysadmins to use, while checkLess.php (verifies less syntax) is really intended for developers. By default when you ask the runner for the list of scripts, it'll provide just the sysadmin ones, and there will be a command-line flag so you can ask for the developer ones as well. We could probably add a basic search functionality of descriptions.

For core the registry will be some static arrays in a class, and for extensions it'll be in extension.json. It'll map the human name to the class name. For example,.

Entry point
It'll be called maintenance.php in the root directory. If you pass it no arguments, it'll output a list of sysadmin scripts that can be run. Adding something like  will have it output development ones instead.

Syntax:  (for update.php),   (for extension scripts). There will also need to be a way to run scripts out of the registry for e.g. local hacks.