Rethink how we use aliases (and don't break custom ones)

Indeed, the relevant code in vagrant.drush.load.inc is:

  $alias = drush_get_context('alias');
    // Ensure we're using a group alias
    if (isset($alias['#name']) && !isset($alias['type'])) {
      // Remove the project alias from the site-list
      if (array_shift($alias['site-list']) == $alias['#name'] . '.project') {
        drush_set_context('alias', $alias);
      }
    }

The idea here was to remove the 'project' alias from the site-list, so that we could use the group alias to run commands on all VMs. For the time-being, I've just commented it out, since it doesn't accomplish much of use at this point.

While I'd like to figure out a better solution,

reworking the existing code to not interfere with non-vagrant aliases would probably be worthwhile.

This line was a quick hack, and the part that most needs replacing:

if (isset($alias['#name']) && !isset($alias['type']))

Unless things have changed in Drush 5.x, any manipulation of aliases has to happen in hook_drush_load(), at which point we have very minimal context. Perhaps we could add a global option to the alias file that we can test for, to ensure we're only messing with drush-vagrant aliases...

The original issue should be fixed in http://drupalcode.org/project/drush-vagrant.git/commit/4f4364991c25ea183...

We just check that we're in a group alias and that the 'project-path' option is set in the alias, which should uniquely identify drush-vagrant aliases.

So what remains is to test that this now works with custom aliases, and seeing if we can come up with a better use of aliases.

In http://drupal.org/node/1779866#comment-6457526, Steven points out that the command array can be extended pretty much however we like. This seems like a good way to proceed with:

... merge (2) and (3), by specifying which commands operate on the project as a whole (e.g., vagrant-delete, vagrant-aliases, &c.) vs. those meant to operate on individual VMs (vagrant-shell & most native vagrant commands). This could become a maintenance nightmare though, and I don't see any way to reasonably manage commands provided by Vagrant extensions.

So, adding a 'vagrant_scope' parameter that defaults to 'vm', but that allows us to specify 'project' seems like a good start. With that, we can call @project_alias, dropping the '.project', and generally get the desired behaviour. Assuming a vm scope will have drush-vagrant dispatch batch operations, rather than letting Vagrant figure that out on its own, but since we do still have the @project_alias.project notation available, we can override it.

To do so, we'll need to remove @project_alias.project from the 'site list', since it'll likely fail whenever we're calling a batch operation. Ideally we'd remove them from 'drush sa' listings too, since they're just clutter now.

I think we should do this in vagrant_drush_init():

if (!drush_get_context('alias', FALSE)) {
  $this_project_name = get_current_project_name();
  $alias = drush_sitealias_get_record("@${this_project_name}.project");
  drush_set_context('alias', $alias);
}

It would load the alias when we are in a project. This would, in turn, allow us to prompt for the VM, if given a command that should only apply to a VM.

We now load an alias (if available) whenever we're in (or under) a Vagrant project.

update summary to address the underlying issue