[core] Remove bundler usage for plugin management

[chrisroberts]

Remove bundler usage for internal plugin management.

[mitchellh]

LGTM! I don't understand it 100% but trust you and nothing popped out as worrying.

[gildegoma]

I bring my two cents here, after I've just noticed that the plugins auto-loading is no longer disabled when running Vagrant from a Bundler environment. This is "breaking" my Vagrant installation from source, as Vagrant now tries to load all the plugins defined in ~/.vagrant.d/plugins.json, but fails to find them in such context.

Thanks to the new VAGRANT_DISABLE_PLUGIN_INIT environment variable, I can force to disable the plugins initialisation, which is fair enough for working on the Vagrant project itself.

@chrisroberts In order to avoid misunderstanding situations for people wanting to contribute to the Vagrant project, I guess it would probably be worth to

• consider disabling the plugin auto-loading by default when running in a "development" context (or be sure to not conflict with plugins installed in an official Vagrant setup).
• update the related README.md section, especially the note copied below

NOTE: By default running Vagrant via bundle will disable plugins.
This is necessary because Vagrant creates its own private Bundler context
(it does not respect your Gemfile), because it uses Bundler to manage plugin
dependencies.

What do you think? Sorry if I missed something obvious, as I haven't taken time to fully understand the changes brought here. I merely wanted to report a "contributor experience" feedback. Hope it helps and makes sense for you...

[chrisroberts]

@gildegoma Hi! Thanks very much for the feedback. I did miss that section in the README file and will need to update it. But to the bigger issue around the behavior of package installation vs source installation around plugins, I'm really happy to get this feedback.

I'm trying to make the behavior of Vagrant from a package installation context and a source installation running via Bundler context function in mostly the same way. This unexpected breakage was "expected" from an implementation point of view, but not intentional from a usability point of view for contributors. My apologies!

I would like for plugins to remain auto loading regardless of the running context (so I'll definitely update that portion of the README, and the relevant section in the website docs). I am curious on thoughts around context specific plugins files and installations. It was something I was considering originally, and perhaps might be worthwhile. This would allow switching from a package installation context to a source installation context without needing to run a plugin repair or plugin expunge --reinstall.

Any more thoughts/feedback is very welcome. Cheers!

[Ma27]

this seems to break the installation of vagrant-r10k.

Whenever I run vagrant plugin install vagrant-r10k with Vagrant 1.9 I get this:

/opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/dependency.rb:315:in `to_specs': Could not find 'faraday_middleware' (>= 0) among 45 total gem(s) (Gem::LoadError)

[gabriel403]

I get something similar with vagrant-librarian-puppet

/opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/dependency.rb:315:in `to_specs': Could not find 'faraday' (< 1.0, >= 0.7.4) among 45 total gem(s) (Gem::LoadError)

edit:
reverting to vagrant 1.8.7 seems to fix the issue

[Ma27]

yeah, it seems as the new installation process destructs all vagrant plugins if they use runtime dependencies (both rely on the faraday gem)

…

Am 06.12.2016 um 08:23 schrieb Gabriel Baker ***@***.***>: I get something similar with vagrant-librarian-puppet /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/dependency.rb:315:in `to_specs': Could not find 'faraday' (< 1.0, >= 0.7.4) among 45 total gem(s) (Gem::LoadError) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Ma27]

ping @chrisroberts is this reproducable from your side?

[chrisroberts]

@Ma27 yep, and has been fixed in #8068

[Ma27]

cool, thank you :)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.