This is really a question of what users' expectations are of Drush Vagrant.

Using Drush Vagrant, we can act on new or existing projects remotely since this is passed as the first argument to most of the current Drush commands. Once we work out #1532506: Drush aliases for VMs, we'll (hopefully) have native Drush aliases for our VMs. This is useful on it's own, since it avoids having to change directories to run Vagrant commands (i.e., remote control).

However, will users expect Drush Vagrant to act on projects the same way that Vagrant would natively? If users are already familiar with Vagrant, the Principle of least astonishment might suggest that drush vagrant @VM init should act pretty much like running vagrant init within the ~/vagrant/projects/VM directory. This is not the case currently, as drush vagrant-initialize uses a blueprint, and links to our Vagrantfile. The same goes for drush vagrant-ssh which will connect using the host user's account, rather than the default 'vagrant' user.

If that's the case, then we should basically just pass through any native Vagrant commands, and ensure that we implement our own commands using different names. That was my reasoning for using drush vagrant-delete over drush vagrant-destroy, since vagrant destroy only destroys the VMs, but leaves the project intact, whereas drush vagrant-delete destroys the VMs, deletes the project directory and removes any /etc/hosts entries associated with the project.

However, it seems to me that this also then implies that we should support passing through all Vagrant native commands. It could also lead to namespace collisions, if Vagrant were to add a new command using the same name as one we'd separately implemented. We could add something like a --native option that would bypass Drush Vagrant implementations.

I feel our target audience is experienced Drupal developers and Drush users, rather than experienced Vagrant users. Also, Vagrant commands can still be run directly. So, it might not be worth doing any of this. Either way, I don't feel I can objectively evaluate this issue, but I'd still like to make explicit what to expect from Drush Vagrant commands.

So, as a potential users, what are your thoughts?

Comments

ergonlogic’s picture

I implemented basic pass-through functionality that allows the use of native Vagrant commands, while passing --project-path=/path/to/project and --vm-name=... options for remote control. A third option, --params='...', allows passing additional parameters and options to Vagrant. Note that these options pave the way for #1532506: Drush aliases for VMs.

We'll have to rename a couple of our commands to avoid confusion. These are:

  • initialize/init -> 'build'?
  • ssh -> 'shell'?
  • status -> 'projects'?
ergonlogic’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.