[chef-dev] Re: Re: Ohai Ruby plugin: system ruby vs. running ruby?

[Daniel DeLeo < >]

On Wednesday, August 31, 2011 at 1:32 PM, Jesse Nelson wrote:
> I see the need to differentiate the chef ruby (using rbconf) to figure
> out what chef is running under. assuming you may need this for
> developing some in-recipe things. I.e. i want to detect ruby 1.8 or
> 1.9 in my recipe. I know we can do that other ways in the recipe but
> node['ruby"]["chef"]["version"] makes sense to me.
> 
> I think pulling all other rubies is also good. For the times when i
> want to unsure some other script code or framework will work.
> node["ruby"]["system"]["jruby"]
> 
> I also see that you would want to detect the available rubies under
> rvm. node["ruby"]["rvm"] for similar reasons.
> 
> 
For the sake of argument, you could use RUBY_VERSION to get the version of 
ruby that your code is running under. But this will be less obvious to Chef 
users who are used to getting that data via the node object (via ohai).

I think rvm support in ohai would be great. Does it belong in the core ruby 
plugin, or in a separate plugin?

I also see merit in reporting all the rubies that ohai can find. Is there a 
clean way to do this without breaking existing recipes that use ohai's 
current ruby plugin? What should ohai search for?

-- 
Dan DeLeo 
> 
> 
> On Wed, Aug 31, 2011 at 1:03 PM, Daniel DeLeo 
> <
 
>  
> (mailto:
 )>
>  wrote:
> > On Wednesday, August 31, 2011 at 12:59 PM, Brad Knowles wrote:
> > > On Aug 31, 2011, at 2:52 PM, Daniel DeLeo wrote:
> > > 
> > > > So, if your ohai attributes for languages/ruby are empty, what breaks?
> > > 
> > > In my case, everything related to Chef. The system-provided version of 
> > > ruby & rubygems is old enough that it will not work with anything 
> > > related to Chef, and yet there are other parts of the system that are 
> > > dependent on that older version being installed and being installed in 
> > > the system-standard place. And they probably also do stupid things like 
> > > assuming that the path is always set up correctly so if they just shell 
> > > out to "ruby" it will pick up the right system-provided version.
> > > 
> > > 
> > > So, I can't upgrade the system-provided version of ruby & ruby-gems, 
> > > but I have to have the newer version of ruby & ruby-gems in order to 
> > > get Chef & ohai to work.
> > > 
> > > Both code bases want to assume that there is one and only one 
> > > installation of ruby on the system, and it is necessarily the version 
> > > that they need.
> > > 
> > > That's a majorly, heinously, bad assumption.
> > > 
> > > 
> > > You can't go back and fix all the legacy code that wants to make that 
> > > one-and-only-one assumption, but you can at least ensure that all the 
> > > new code will always be able to find the right version that it actually 
> > > needs, without breaking or otherwise causing any disturbance for any of 
> > > the older code.
> > > 
> > > So, if you're going to program in Ruby, and you're going to build a 
> > > system that requires newer version of the code than what we can get 
> > > with a system-standard install, then the requirement falls onto you to 
> > > make sure that you make things work properly. Don't break my existing 
> > > production systems with your new code, and don't make me jump through 
> > > hoops to get two incompatible versions installed.
> > > 
> > > --
> > > Brad Knowles 
> > > <
 
> > >  
> > > (mailto:
 )>
> > The change that I'm talking about is only related to how ohai collects 
> > data about what ruby you have installed on the system. In Chef you can 
> > access this data as node[:languages][:ruby]. Are you currently depending 
> > on this data to return information about the system ruby?
> > 
> > --
> > Dan DeLeo