-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add a chruby_gem LWRP #5
Comments
Ignore above comment. That should be for issue #4 Re: LWRP: Postmodern suggests using chruby-exec. Investigating. |
I would lean towards a bundler style syntax:
|
There's some restriction around the way LWRPs work - the DSL keyword needs to be How about:
Easiest to implement would be:
I think this is how the What do you think? |
I don't know how LWRPs work, but I would favour the least repetitious / "blocky" syntax. |
I would expect chruby-exec 392 to only install the Gem for that Ruby. But it seems that Gem is available to all Rubies? Is this what you would expect? Or have I missed something? |
Actually this is an artifact of how chruby sets |
Aha; So embedded Ruby is also 1.9.3; so if I asked ruby_build to install something other than 1.9.3, and then ran chruby_exec somthingelse -- gem install, we'd get the behaviour I expected. |
Correct. |
Tested with 2.0.0-p195 - behaves as expected. Next question is how to call chruby-exec from Chef. Two obvious options:
chruby-exec is actually a Bash function, I guess, so I'll need to source chruby first. Something like:
|
|
Wonder what the best way to guarantee idempotence is. Best would be to look at the file or directory it creates, which could be calculated. Alternative would be to run gem list and look for the thing we're trying to install. Thoughts? |
Current |
Aha okay, so I guess I don't need to source chruby in that case. Any thoughts on idempotence? |
Just installing the gems should be idempotent? |
Do you mean that Rubygems itself is idempotent? is if bundler is installed, when I try to install bundler, no action will be taken? I guess I should just look at the core Chef provider and see what that does. |
It will just install the latest version, even if that version is already installed. |
Right - that's what I thought. Ideally a provider knows if action is needed, to save node convergence time. |
Bump! I'm also looking for a reliable way to install gems (like bundler) - ideally at the system level - using the chruby cookbook. FWIW, my "gem_require" gem (https://github.com/mdub/gem_require) provides an idempotent version of "gem install". |
A simple solution that works for me is the following define :chruby_gem, :action => :install do
gem_package "chruby #{params[:ruby]}: #{params[:name]}" do
package_name params[:name]
gem_binary "/opt/rubies/#{params[:ruby]}/bin/gem"
version params[:version] if params[:version]
action params[:action]
end
end The gem_packe resource also handles the idempotency for us: chruby_gem 'bundler' do
ruby '1.9.3-p448'
end Gives me on a second run:
|
@databus23's solution works great. But i think we can use it without proxy-definition gem_package 'bundler' do
gem_binary "/opt/rubies/#{node[:chruby][:default]}/bin/gem"
end |
This indeed works great, but if you're running chef-client withing a chruby ruby then it is using the correct gem command, but it's used withing the ruby environment you're running. For now the only workaround is to run chef in a ruby not managed by chruby. In my case on OSX I would need to use the system ruby. |
It would be great to be able to specify gems to install per Ruby:
For example:
chruby_gem "bundler" do
ruby "1.9.3-p429"
end
The text was updated successfully, but these errors were encountered: