Enable/Disable plugins on a per Vagrantfile basis #1574

Closed
reset opened this Issue Apr 10, 2013 · 17 comments

Projects

None yet
@reset
Contributor
reset commented Apr 10, 2013

Some plugins may not fit for every project that is leveraging Vagrant. As is, all plugins which are installed are loaded when Vagrant starts. It would be awesome if a plugin author had the option to lazily load their plugins and require users to manually require these plugins in their Vagrantfile.

A good example plugin which may not need to be loaded for every project is Berkshelf-Vagrant. We're currently taking steps to add our own 'enable' configuration flag which will cause the middleware to do a no-op.

@bflad
bflad commented May 16, 2013

Sort of relates to #1700 as well if implemented correctly.

I could envision the Vagrantfile then accepting something like:

Vagrant.configure("2") do |config|
  # simple load
  config.plugin 'vagrant-berkshelf'
  # maybe more advanced logic
  config.plugin 'vagrant-berkshelf' do |plugin|
    plugin.version '>1.2.0'
  end
  #...
end

Where it could install the plugin automatically if it's not available and fix your lazy loading issue.

For reference, here's the offending code when a Vagrant environment is spinning up that loads all external plugins:
https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/environment.rb#L132
https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/environment.rb#L742-L776

Maybe the load_plugins function should be unprotected or moved closer to the Vagrant kernel and optionally take an array of plugins to load (nil loading all)?

@fgrehm
Collaborator
fgrehm commented Jul 15, 2013

Hey guys, here's my take on the problem: https://github.com/fgrehm/vundler :)

@mitchellh
Owner

I think for now delegating this out to Vundler is ideal. Closing.

@mitchellh mitchellh closed this Jul 17, 2013
@erunion
erunion commented Aug 23, 2013

Why not move it into core instead of having to have everyone use a plugin to manage plugins?

@leifmadsen

Yo dawg, I heard you like plugins, so we let you manage your plugins with a plugin.

@mitchellh
Owner

The goal is to eventually move this into core, but this provides a good stand-in.

@nikolay
nikolay commented Aug 23, 2013

👍 This definitely should be part of the core and I hope to see it there soon!

@nikolay
nikolay commented Aug 23, 2013

I though like the approach of specifying dependency plugins in https://github.com/tknerr/vagrant-plugin-bundler better than with Binder as the vast majority of projects won't have too many plugins and having a separate file is a bit of a overkill. You can with the approach of vagrant-plugin-bundler, you can parse an external file in .json, .yml, or any other format easily (if you really need it). What if those dependencies are determined at runtime, etc.

@erunion
erunion commented Aug 24, 2013

@mitchellh Awesome.

@gregelin
gregelin commented Oct 4, 2013

Please, please include this in the core. Typing vagrant up is magic. Having to separately install anything diminishes the magic.

@imduffy15

Why is this closed? vagrant-plugin-bundler and Vundler are both unmaintained leaving this unsolved.

@dasgoll
dasgoll commented Apr 12, 2015

Shouldn't this fucntionality be in core??

@jhoblitt

I'm running into vagrant-librarian-puppet being incompatible with puppet-aws when its parallelizing. It would be great to not have to uninstall a plugin to disable it...

@amosshapira

Same situation as @jhoblitt - I use vagrant-vbguest which only supports Linux, so it breaks my OSX Vagrant boxes...

@chillum
chillum commented Aug 30, 2016

Same situation as @amontalban, vargrant-vbguest works with Linux, but breaks FreeBSD.

@varac
varac commented Jan 31, 2017

I love vagrant-sshfs which works great for vagrant-libvirt but breaks with vagrant-lxc :(
So @mitchellh please consider this functionality in vagrant-core, because the the workaround you proposed isn't valid anymore now that vundler is not maintained anymore.

@robinbowes

Really? Is there no native way to disable plugins on a per-environment basis?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment