Add support for command specific config files

So this file gets loaded instead of drushrc.php, and not in addition to? Thats a bit surprising, IMO. Anyway, I'm a bit skeptical on this. We have lived pretty successfully with command_specific. I want to keep drush s simple as possible and our myriad of searchpaths is complex enough. This adds another gotcha. Am open to opinions from others here.

An individual user can always add something like:

include_once("deploy.drushrc.php");

in their drushrc.php file, and copy all of the deploy settings into this auxiliary file, if desired. I see no reason to add complexity or try to increase performance by only loading these options when a deploy command is invoked.

We do special stuff for alias files because Aegir might have a thousand different aliases. I don't think that quite applies here.

I think this is Won't Fix. Perhaps deploy could ship with its own deploy.drushrc.php which tells folks to copy and paste into another drushrc or it could instruct folks to copy and include it.

Looks good. If you could add some doxygen explaining $prefix that would be swell.

At Mark's suggestion I'm providing some new input here. I'm not sure if it argues for or against his proposed change. :-)

I wanted a command-specific (actually, a command-file-specific) drushrc file to store common options for a set of commands. I ended up doing this:

/**
 * Define common options for Acquia Cloud API commands, and their defaults.
 */
function ahapi_common_options() {
  $options = array(
    'username' => array(
      'description' => 'Acquia Cloud API username',
      'default_value' => '',
      'example-value' => 'username',
    ),
    ... more options here ...
   );
   return $options;
}

/**
 * Retrieve an Acquia Cloud API default option.
 *
 * @param $name
 *   An ah-api option name.
 * @return
 *   The option's configured value, or the default value from
 *   ahapi_common_options().
 */
function ahapi_get_option($name) {
  drush_load_config_file('home.drush', _drush_config_file('home.drush', 'ahapi'));
  $options = ahapi_common_options();
  if (!isset($options[$name])) {
    return drush_set_error('AHAPI_UNKNOWN_OPTION', dt('Unknown ah-api option @name.', array('@name' => $name)));
  }
  return drush_get_option($name, $options[$name]['default_value']);
}

Then I use ahapi_get_option('name') instead of drush_get_option('name', 'default') for my common options, but continue using drush_get_option() for normal/global options like simulate, verbose, and debug. By loading ~/.drush/ahapi.drushrc.php via drush_load_config_file() at the top of ahapi_get_option(), I am able to store my commandfile-specific defaults there. I have a command, ah-api-login, that prompts for username/password and stashes it there.

After some amount of confusion and concern that by storing $options['username'] in ~/.drush/ahapi.drushrc.php I was polluting the global namespace, Mark, Moshe, and I came to the conclusion that ahapi.drushrc.php will never be loaded automatically by Drush; it is loaded only by my call to drush_load_config_file(), which only happens when one of my commands is running.

I guess the upshot is that if I could specify 'config' => 'ahapi' in my commands returned from ahapi_drush_command(), it would simplify my code slightly by removing the explicit call to drush_load_config_file(), and it would have simplified my life somewhat more by making it easier for me to create this setup instead of having to go figure out how drush_load_config_file() works.