Commands defined in Vagrantfiles not working since 1.6.0

[jsoriano]

Commands defined in Vagrantfiles stop working in 1.6.0, as a minimal example, consider this Vagrantfile:

VAGRANTFILE_API_VERSION = "2"

class MyCommand < Vagrant.plugin(VAGRANTFILE_API_VERSION, :command)
  def self.synopsis
    "Says Hello"
  end

  def execute
    puts "Hello"
    0
  end
end

class MyPlugin < Vagrant.plugin(VAGRANTFILE_API_VERSION)
  name "My Plugin"

  command "mycommand" do
    MyCommand
  end
end

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "base"
end

Till 1.5.4 this code provides a command called mycommand that appears in vagrant list-commands and that can be called as vagrant mycommand, but from 1.6.0 the command disappears.

Is this using some deprecated code? In principle vagrant 1.6 is supposed to be backwards compatible.

[drpebcak]

@jsoriano vagrant only promises that there will be no breaking changes between patch releases. Check the release notes to see if you are affected by those underlying changes.

[mitchellh]

Not a bug according to our backwards compat promise, @drpebcak is correct.

I'm actually not sure why this stopped working though I suspect it is because we're becoming a bit more strict of when we parse Vagrantfiles in order to improve performance in some cases. The Vagrantfile is only TRULY meant to describe the development environment, and not also be a plugin host. It only worked as a plugin host as a side effect of Ruby just putting everything in the global namespace, but it was never documented.

[jsoriano]

Thanks for the explanation.

Is there any way to have a plugin installed only for a development environment and not system-wide?

[mitchellh]

Not at the moment, though there are open bugs for that.

[drpebcak]

@jsoriano although you could install the plugin system-wide, but only enable it per project with a special line in the Vagrantfile!

[atdt]

I can confirm that this has to do with the order in which files are evaluated. It'd be tremendously helpful if this functionality was restored. At the Wikimedia Foundation, we extend Vagrant with a few subcommands that are specifically designed to work with the Vagrant setup that we use, and it was a tremendous boon to be able to ship those in one repository without encumbering the setup process with additional steps. The plugin is not generic enough to be useful outside the context of our particular setup, so tightly coupling it to the Puppet code and Vagrantfile was expedient.

Perhaps there could be some other file in the project root that, if it exists, would be evaluated sooner?

[jsoriano]

In Tuenti we have a similar problem, we have a plugin quite coupled to an scenario we use for testing and we load it directly from the Vagrantfile, it's probably a bit hacky, but fits very well for our case.
We'll have to think something for 1.6+ if previous behaviour is not restored.

[mitchellh]

I'll think about this and see if we can bring this back.

[KenjiTakahashi]

👍 on this. Right now we just stick with the 1.5.x branch, as it works perfect for us. But it would be nice to have some way to include "project-coupled" extensions without additional hassle from other developers who just want to use them.

[bd808]

Any progress on this issue? It's a major issue for the MediaWiki-Vagrant project. We could probably find some folks to help with implementation if there is a clear path forward.

[markjaquith]

Gem-based plugins are really laborious to produce, and hard to project-couple. Being able to require_relative out to a Ruby file from within Vagrantfile was really awesome, as all someone had to do to run your environment and get your custom commands was clone the repo. Now those commands have just silently disappeared.

The systemwide gem-based plugin system isn't a viable substitute for this use case. What could be a substitute is some sort of way in a Vagrantfile to say "hey, include this file during the plugin bootstrap process".

[mitchellh]

No progress, and let me reopen to make sure I try to fix this.

[atdt]

The code for setting up bundled subcommands doesn't have to reside in the Vagrantfile, if it is important to defer evaluation of that file. There could be some other file which, if present, gets evaluated sooner.

[marxarelli]

What about extending Vagrant::Plugin::Manager to look for a plugins.conf in the current working directory (or rather the directory containing the Vagrantfile)? This seems congruent with the current hierarchy of system- and user-wide configs.

[myoung34]

This is also an issue for my team, as we have a command that is useless as a full plugin, but is quite useful for syntactic sugar. We're sticking with 1.5.4 to keep it, but having the ability to load commands and provisioners relative to the vagrantfile without having to package them is almost a must for my setup.

[sirupsen]

This has prevented our organization from upgrading Vagrant for months now. Any progress on this @mitchellh? Really don't want to fall behind another minor version.

[etuttle]

My team also relies on inline commands, so until this is sorted out we're sticking with v1.5.

[mitchellh]

Done. The compromise I've found is to load a ".vagrantplugins" in the same folder as your Vagrantfile. This can be arbitrary Ruby with plugins. Enjoy!

[bd808]

Thanks @mitchellh. This looks like it will be nice fix for an annoying problem.

[atdt]

Thank you! ❤️

[jsoriano]

Thanks @mitchellh !

[myoung34]

@mitchellh Any idea what release this will be in?
1.6.5 was release 9/4, no releases since. I'm assuming either 1.6.5 or 1.7?

[jglick]

Since 1.7.0 according to the GitHub commit. Seems to work in 1.7.2.