Enhancement: Vagrant.require_plugin('bar', '1.0')

[till]

So, I added a version parameter to require_plugin, hoping to add support to load/enforce
a specific version of a plugin when this is used in a Vagrantfile.

Right now struggling to write a proper unit or acceptance test for it since I seem to be
unable to install plugins on the fly or within a bundler environment.

Feedback welcome.

[tmatilai]

What if it it would accept (a list of) Gem requirement string, for example ~> 1.0?

The code would be something like:

if !Gem::Requirement.new(version).satisfied_by?(Gem::Version.new(plugin_version))

[phinze]

Ooo I like the idea of a Gem requirement string. It's already a standard and it's super-flexible.

[till]

@tmatilai @phinze That's a great idea, wasn't aware of it. I'll try to do this tomorrow.

[till]

@tmatilai @phinze Either of you have an idea how to write a test for it. Struggling hard with it. To be more specific: the part where I need to write some kind of plugin, register it and test against it.

[phinze]

@till let me see if I can work a test out with some stubbing action.

I'm also experimenting to see if Kernel#gem might make the code any simpler.

[phinze]

So here is what I came up with: phinze@cdcb630

Couple of things I figured out playing with it:

• Kernel#gem will actually select a gem version when multiple versions are installed. This makes the behavior more flexible for code that wants to require older versions of plugins.
• Unit tests aren't that bad with a little stubbing.
• The actual exception handling logic is still a little hairy since you need to call gem before require but when gem blows up you can't tell if it's because it's just not installed or if it's a version problem. So you have to require again to be sure. Not the greatest, but it was the best I could come up with.

@till Do you want me to re-PR with my revisions, you want to make your own edits, or you want to discuss here more?

I'm down for whatever! ⏬

[tmatilai]

I didn't even know about Kernel#gem. Nice to learn new things every day. =)

But you won't have multiple gem/plugin versions installed with Vagrant. The plugin commands call PruneGems action which cleans up the gem store.

[till]

@phinze I agree with @tmatilai — thanks for doing this. Do you want to PR your changes to me? I am more than happy^W^thankful to include them.

Also, good to know on PruneGems. :)

[phinze]

Ooo well I didn't know about PruneGems!

Hmm, if only one version of a plugin can be installed at any one time, it may be cleaner to do something closer to your strategy. @till - I'll send you a PR with what I'm thinking.

[phinze]

Alright PR'd at easybiblabs#1

[till]

@phinze @tmatilai Integrated and pushed. Thanks for helping!

[tmatilai]

👍 LGTM

[mitchellh]

LGTM

[mitchellh]

Hold off on merging this for a second. I want to think further about plugin dependency management.

[till]

@mitchellh HNY — that was a long second. Any thoughts?

[mitchellh]

@till Yes I'm actually going through this now. It is a difficult problem. I'm trying to actually solve the entire dependency resolution problem of plugins in their entirety.

[mitchellh]

This won't be necessary anymore with the f-bundlerize branch: https://github.com/mitchellh/vagrant/compare/f-bundlerize (work-in-progress).

Plugins are now loaded all at once at the beginning of Vagrant. So we'll need another method to describe the requirements. But either way, this won't work here.