[chef-dev] Re: Re: Re: Re: dependency spaghetti


Chronological Thread 
  • From: Dimitri Aivaliotis < >
  • To: Noah Kantrowitz < >
  • Cc: Bryan Taylor < >, Blake Irvin < >, " Dev" < >
  • Subject: [chef-dev] Re: Re: Re: Re: dependency spaghetti
  • Date: Thu, 3 Oct 2013 09:25:39 +0200

On Thu, Oct 3, 2013 at 8:48 AM, Noah Kantrowitz 
< >
 wrote:
>
> The cookbook metadata isn't actually code, the Ruby format is just 
> convenience so you don't have to write the (rather long and complex) JSON 
> yourself. More specifically the cookbook dependency tree is resolved on the 
> server, not the client, so whatever the solution is it has to be fully 
> declarative.
>

I'm aware of that, but I find that a weakness in the current
implementation.  The resolved dependency tree can be further filtered
on the client to eliminate cookbooks not supported on the running
platform.

Why is there a "platforms" object if it's not currently used to
resolve dependencies?  It doesn't (any longer) restrict a specific
cookbook from being installed on a particular platform, e.g. the
windows cookbook "supports" only windows, but can be (and must be, due
to the dependencies the OP mentioned) installed on any platform.  Is
this another appendix in Chef, in the sense that it originally had a
purpose, but now seems to be unused?

While we're talking of dialects and alternative formats anyways, how
much more of a stretch would it be to extend the Ruby format to
generate an alternative JSON serialization, one in which the
"dependencies" object is nested under "platforms"?  I realize that
this may actually have a greater impact than taking the two objects on
the client and filtering out the cookbooks not supported on that
platform, which may be the easiest near-term solution.

- Dimitri



Archive powered by MHonArc 2.6.16.

§