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

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

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@till
Contributor

till commented Dec 7, 2013

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.

WIP: a first shot at Vagrant.require_plugin('bar', '1.0')
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

This comment has been minimized.

Show comment
Hide comment
@tmatilai

tmatilai Dec 7, 2013

Collaborator

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))
Collaborator

tmatilai commented Dec 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Dec 7, 2013

Member

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

Member

phinze commented Dec 7, 2013

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

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Dec 8, 2013

Contributor

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

Contributor

till commented Dec 8, 2013

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

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Dec 8, 2013

Contributor

@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.

Contributor

till commented Dec 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Dec 8, 2013

Member

@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.

Member

phinze commented Dec 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Dec 8, 2013

Member

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!

Member

phinze commented Dec 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@tmatilai

tmatilai Dec 9, 2013

Collaborator

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.

Collaborator

tmatilai commented Dec 9, 2013

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

This comment has been minimized.

Show comment
Hide comment
@till

till Dec 9, 2013

Contributor

@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. :)

Contributor

till commented Dec 9, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Dec 10, 2013

Member

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.

Member

phinze commented Dec 10, 2013

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.

core: tweaks require_plugin version
 - use a rubygems version specification
 - add a test
 - raise a specific error
@phinze

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Dec 10, 2013

Member

Alright PR'd at easybiblabs#1

Member

phinze commented Dec 10, 2013

Alright PR'd at easybiblabs#1

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Dec 10, 2013

Contributor

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

Contributor

till commented Dec 10, 2013

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

@tmatilai

This comment has been minimized.

Show comment
Hide comment
@tmatilai

tmatilai Dec 10, 2013

Collaborator

👍 LGTM

Collaborator

tmatilai commented Dec 10, 2013

👍 LGTM

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Dec 10, 2013

Member

LGTM

Member

mitchellh commented Dec 10, 2013

LGTM

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Dec 11, 2013

Member

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

Member

mitchellh commented Dec 11, 2013

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

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Jan 3, 2014

Contributor

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

Contributor

till commented Jan 3, 2014

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

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jan 3, 2014

Member

@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.

Member

mitchellh commented Jan 3, 2014

@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 comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jan 5, 2014

Member

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.

Member

mitchellh commented Jan 5, 2014

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.

@mitchellh mitchellh closed this Jan 5, 2014

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