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


Chronological Thread 
  • From: Adam Jacob < >
  • To: Brad Knowles < >
  • Cc: Daniel DeLeo < >, Chef Dev < >
  • Subject: [chef-dev] Re: Re: Ohai Ruby plugin: system ruby vs. running ruby?
  • Date: Wed, 31 Aug 2011 16:29:25 -0700

Brad, why do you need to include /opt/opscode/embedded/bin in the
path? All the binaries that omnibus installs are using the right
interpreter on the shebang line, so this should not be needed at all.

Adam

On Wed, Aug 31, 2011 at 1:25 PM, Brad Knowles 
< >
 wrote:
> On Aug 31, 2011, at 3:03 PM, Daniel DeLeo wrote:
>
>> 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?
>
> Right now, we're just trying to figure out how to use Chef to help us 
> rebuild our infrastructure so that it is more manageable and scalable.  The 
> Omnibus installer goes a way towards that, but there is still the issue of 
> having to set the user's path environment variable to include the 
> /opt/opscode/embedded/bin directory before anything else because replacing 
> the standard system-provided version of /usr/bin/ruby with symlinks to the 
> new binary would cause all the old system-provided programs to break.
>
> This is CentOS 5.6.  We're not back on RHEL4 or CentOS 5.1 or something -- 
> this is relatively recent, to the degree that anything from RHEL/CentOS is 
> recent.
>
>
> We're not currently actually using Chef or ohai for anything, but if the 
> code depends on a specific version of ruby & ruby-gems being installed and 
> that version is different from what the standard system-provided version 
> is, then you need to find a way to handle that exception within your own 
> code.  This problem should be handled at compile/install time, so that I 
> don't even have to modify the user path environment variable to include the 
> new embedded subdirectory location.
>
> You need to decide how you're going to handle potentially having several 
> different versions of the same program installed (think multiple versions 
> of python as well as ruby, etc...).  Our code doesn't care, at least not at 
> the moment.  But you can be assured that whatever code we do have that 
> might be sensitive to what version of what program is installed, we will 
> handle the pathing/location issues to that within our own code.
>
> --
> Brad Knowles 
> < >
>
>



-- 
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: 




Archive powered by MHonArc 2.6.16.

§