Last modified: 2014-07-10 00:17:44 UTC
On Win 8.1 x64, vagrant 1.6.3, after running I748655162214e0 - setup.bat to get all the custom commands. Custom commands such as list-roles, enable-role, etc work ok from the root Vagrant dir, but fail when executed from subdirectories: cd v (vagrant dir) $ vagrant list-roles ... works ok $ cd mediawiki $ vagrant list-roles Available roles: C:/Users/user/.vagrant.d/gems/gems/mediawiki-vagrant-0.0.3/lib/mediawiki-vagrant/roles.rb:12:in `each_slice': invalid slice size (ArgumentEr ror) from C:/Users/user/.vagrant.d/gems/gems/mediawiki-vagrant-0.0.3/lib/mediawiki-vagrant/roles.rb:12:in `execute' from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/cli.rb:42:in `execute' from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/environment.rb:252:in `cli' from c:/HashiCorp/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.3/bin/vagrant:166:in `<main>'
This have been my experience on OS X with the plugin based system as well. I'm pretty sure this is caused by the changes in Vagrant 1.6 that cause the plugins to be loaded before the contents of Vagrantfile.
It's likely symptomatic of inconsistent initialization of the $DIR global between older versions of Vagrant and 1.6—related to the inconsistent loading of the plugin, as Bryan mentioned. When using a pre-1.6 version, the plugin was loaded by the Vagrantfile after it had initialized $DIR to the parent directory. In 1.6, the plugin is loaded first and initializes $DIR to the current working directory. The latter scenario leads to a failure to find the vagrant-managed.pp manifest that stores enabled-role state. I think refactoring the roles implementation to derive the directory from the Vagrant::Environment is the way to go here. While I'm at it, I'll see about removing the other globals to avoid these types of race conditions in the future.
One unfortunate consequence of the subcommands-as-gem approach is that the subcommands are present for vagrant everywhere; they are not scoped to the mediawiki-vagrant directory tree. So if you try to "vagrant enable-role hhvm" (for example) outside the mediawiki-vagrant tree, you get "'hhvm' is not a valid role.", which is a bit bizarre. If you invoke 'vagrant list-roles', it's even worse: you get: /Users/ori/.vagrant.d/gems/gems/mediawiki-vagrant-0.0.1/lib/mediawiki-vagrant/roles.rb:12:in `each_slice': invalid slice size (ArgumentError)
With all the trouble with the custom commands in 1.6+, would it make sense to try to convince Vagrant team to bring back/implement per-project custom command support?
(In reply to Yuri Astrakhan from comment #4) > With all the trouble with the custom commands in 1.6+, would it make sense > to try to convince Vagrant team to bring back/implement per-project custom > command support? Yes. Several of us have been trying to keep the issue alive at https://github.com/mitchellh/vagrant/issues/3775
Change 144102 had a related patch set uploaded by Dduvall: Factored out globals and refactored helpers https://gerrit.wikimedia.org/r/144102
Change 144102 merged by jenkins-bot: Factored out globals and refactored helpers https://gerrit.wikimedia.org/r/144102
Requires reinstalling the mediawiki-vagrant plugin to get the latest code: vagrant plugin uninstall mediawiki-vagrant gem build mediawiki-vagrant.gemspec vagrant plugin install mediawiki-vagrant-0.0.3.gem
