drush_invoke : a flexible API for hooking into any and all drush calls.

http://groups.drupal.org/aegir/a-love-letter-to-drush-2.x

All the requirements for this is now in, but i just need to decide how to go ahead with the auto-included files.

In provision currently, provision_invoke looks for [command].provision.inc files to include for the hooks.
It uses the commandfile list for a list of directories to source these files from.

I've found that even though I have a lot more files, these files are much easier to manage, and have a very rigid structure (ie: $command_validate, pre_$command, pre_$command_rollback, $command, $command_rollback, post_$command, post_$command_rollback), which makes them very simple to document and maintain.

Any drush commandfile can provide additional hooks solely by creating a file and adding a function to it.

I'm going to be looking for ways to make this nicer in drush itself. For instance, instead of requiring the use of the 'callback arguments' field, I am going to try and use introspection to match it to the command sent.

Personally, I like reversing the order of the words in the command in the auto-loaded filename (ie: install.provision.inc and not provision.install.inc.). I have too many files starting with 'provision' =P

I am thinking i might actually resurrect the *.command.inc filename.

I'm currently busy porting http://drupal.org/node/380688 , which is an api that call other commands externally.

I need to tackle this to be able to do the provision_invoke port properly.

A major part of how provision_command works currently, is it bubbles a $data reference through all the calls, to allow the various functions to pass information to each other.

At the end of the command, it does a provision_output($data), which returns the structured data.

To be able to allow all commands to be scriptable, I need to change how that data is being passed along. Because the backend port works by publishing this information in the drush_shutdown function (which is now always called) and the shutdown command can't have the data parameter passed to it, I need to provide an api for setting and getting this content.

This also provides additional API safety, as we've had bugs where someone initialized the $data array in their hook, which caused the intra-api communication to bug out.

The output function is the last provision specific function called in provision_invoke, so once the replacement for that is done, I will be able to simply rename the function to drush_invoke and drush_command, and it will just work.

I have this crazy plan to use introspection to make implementing commands with this API even simpler.

The default would be this callback, and you could use the api to add a new command simply by doing (in your own *.drush.inc):

function example_drush_command() {
   $items['apply patch'] = array(
      'description' => dt('Apply a patch to the drupal directory'),
      'arguments' => array(
        'path/to/patch' => 'One or more file paths. Paths may be absolute or relative to the current working dir.',
      ),
   );
   return $items;
}

Then you could just write (either in a conditionally included file, or the *drush.inc) :

  function example_apply_patch_validate($file) {
     // check if the argument is a valid file, or whatever. If you want execution to stop just do a 
     drush_set_error('INVALID_FILENAME', dt('Could not find file @file', array('@file' => $file)));
  }

  function example_pre_apply_patch($file) {
     // do whatever setup you need to do here, such as extracting the file to a temporary location, or making a backup of the database
  }

  function example_apply_patch($file) {
     // Apply the patch, setting an error if it failed.
  }

  function example_apply_patch_rollback($file) {
     // patch only partialy applied, revert the bits that were succesful.
  }

  function example_post_apply_patch($file) {
    // run simpletests, doing a drush_set_error if it fails.
    drush_invoke('simpletest');
  }

  function example_post_apply_patch_rollback($file) {
    // Simpletests failed, run the patch with -R to revert to previous code.
  }

Any command that uses this API could then be re-used in the same php process as drush_invoke('apply patch'), or as a separate process with drush_backend_invoke('apply patch').

You could just add a custom.drush.inc into your ~/.drush directory, that could access any of those hooks. Say for instance a command that emails a dev list (or does an xmlrpc call) if the patch couldn't be applied or the simpletests failed.

I really want this in 2.0.

getting close to a patch.

Here's the patch. It also removes some code re: commandfiles that weren't necessary anymore.

This also ports all the core commands to the invoke api.