-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commands defined in Vagrantfiles not working since 1.6.0 #3775
Comments
@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. |
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. |
Thanks for the explanation. Is there any way to have a plugin installed only for a development environment and not system-wide? |
Not at the moment, though there are open bugs for that. |
@jsoriano although you could install the plugin system-wide, but only enable it per project with a special line in the Vagrantfile! |
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? |
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. |
I'll think about this and see if we can bring this back. |
👍 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. |
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. |
Gem-based plugins are really laborious to produce, and hard to project-couple. Being able to 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 |
No progress, and let me reopen to make sure I try to fix this. |
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. |
What about extending |
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. |
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. |
My team also relies on inline commands, so until this is sorted out we're sticking with v1.5. |
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! |
Thanks @mitchellh. This looks like it will be nice fix for an annoying problem. |
Thank you! ❤️ |
Thanks @mitchellh ! |
@mitchellh Any idea what release this will be in? |
Since 1.7.0 according to the GitHub commit. Seems to work in 1.7.2. |
Commands defined in Vagrantfiles stop working in 1.6.0, as a minimal example, consider this Vagrantfile:
Till 1.5.4 this code provides a command called
mycommand
that appears invagrant list-commands
and that can be called asvagrant 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.
The text was updated successfully, but these errors were encountered: