Chef and Rails incompatibility because of JSON gem

We’re looking to embed chef inside of a rails 3.2.x app, and are running
into incompatibility issues with the JSON gem.

Chef very rigorously requires json (<= 1.6.1, >= 1.4.4) which is
incompatible with what most other gems used in the rails eco-system use.
Not to mention that this is gem is over a year old. I’ve had to go back as
far as chef 0.8.10 to satisfy this json dependency.

Is there a known issue that is preventing chef to upgrading to a newer JSON
gem, or just use yajl-ruby gem?

  • Ketan

I'm guessing you want to make Chef API calls from your Rails app, correct? If so, use Spice (GitHub - danryan/spice: A zesty Chef server API wrapper) as an actual dedicated client API library.

--Noah

On Nov 13, 2012, at 10:07 PM, Ketan Padegaonkar wrote:

We're looking to embed chef inside of a rails 3.2.x app, and are running into incompatibility issues with the JSON gem.

Chef very rigorously requires json (<= 1.6.1, >= 1.4.4) which is incompatible with what most other gems used in the rails eco-system use. Not to mention that this is gem is over a year old. I've had to go back as far as chef 0.8.10 to satisfy this json dependency.

Is there a known issue that is preventing chef to upgrading to a newer JSON gem, or just use yajl-ruby gem?

  • Ketan

If you like the the ActiveRecord/ActiveResource libraries alternative to Spice is Ridley - GitHub - berkshelf/ridley: A reliable Chef API client with a clean syntax

Ridley also has support for executing common Knife like operations within another Ruby app like bootstrapping nodes in parallel and asking them to run Chef client.

--
Jamie Winsor
@resetexistence

On Tuesday, November 13, 2012 at 10:13 PM, Noah Kantrowitz wrote:

I'm guessing you want to make Chef API calls from your Rails app, correct? If so, use Spice (GitHub - danryan/spice: A zesty Chef server API wrapper) as an actual dedicated client API library.

--Noah

On Nov 13, 2012, at 10:07 PM, Ketan Padegaonkar wrote:

We're looking to embed chef inside of a rails 3.2.x app, and are running into incompatibility issues with the JSON gem.

Chef very rigorously requires json (<= 1.6.1, >= 1.4.4) which is incompatible with what most other gems used in the rails eco-system use. Not to mention that this is gem is over a year old. I've had to go back as far as chef 0.8.10 to satisfy this json dependency.

Is there a known issue that is preventing chef to upgrading to a newer JSON gem, or just use yajl-ruby gem?

  • Ketan

On Tuesday, November 13, 2012 at 10:43 PM, Jamie Winsor wrote:

If you like the the ActiveRecord/ActiveResource libraries alternative to Spice is Ridley - GitHub - berkshelf/ridley: A reliable Chef API client with a clean syntax

Ridley also has support for executing common Knife like operations within another Ruby app like bootstrapping nodes in parallel and asking them to run Chef client.

--
Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub

On Tuesday, November 13, 2012 at 10:13 PM, Noah Kantrowitz wrote:

I'm guessing you want to make Chef API calls from your Rails app, correct? If so, use Spice (GitHub - danryan/spice: A zesty Chef server API wrapper) as an actual dedicated client API library.

--Noah

On Nov 13, 2012, at 10:07 PM, Ketan Padegaonkar wrote:

We're looking to embed chef inside of a rails 3.2.x app, and are running into incompatibility issues with the JSON gem.

Chef very rigorously requires json (<= 1.6.1, >= 1.4.4) which is incompatible with what most other gems used in the rails eco-system use. Not to mention that this is gem is over a year old. I've had to go back as far as chef 0.8.10 to satisfy this json dependency.

Is there a known issue that is preventing chef to upgrading to a newer JSON gem, or just use yajl-ruby gem?

To answer the original question, there's no reason why we can't bump the dependency version on JSON -- patches accepted.

The reason we have a strict dependency on the JSON gem version is that in the past, patch releases of the gem have broken Chef or Ohai. Setting a strict dependency has successfully prevented this from happening.

  • Ketan

--
Daniel DeLeo