[chef-dev] Re: Re: Re: Re: Dialect support and loading enhancements

[Noah Kantrowitz < >]

On Oct 2, 2013, at 2:35 PM, Ranjib Dey 
<
 >
 wrote:

> i second dan's comment.  Examples that you have given are not dialects, 
> they are more like rendering system. Salt has it already. Chef already has 
> to_json/from_json and to_text support for resources (albeit the to_text 
> method is buggy), so you should be able to  communicate with chef or use 
> chef components as it is, as long as the other system is eating/spitting 
> json. If you want to write a component in other language, why not take that 
> route?

The "other system" in question is humans, and JSON is awesome as an 
interchange format but not as nice for human-authored stuff.

> 
> It makes more sense to make to json support in core chef more stable and 
> extensible. 
> 
> Also i find it hard to understand that yaml or json is more readable than 
> their ruby counterpart.  they look and feel readable in low volume, but  at 
> large scale, they are nightmare. they were meant for serialization, why you 
> want to check them inside code base, when you can generate the same with 
> smaller codebase using a language ?
> 

1) data bags don't have a Ruby DSL nor would that probably help much and 2) 
there is some resistance to using the Ruby DSL for roles/envs because it 
can't really be made compatible with knife diff, Yaml is somewhat of a 
compromise there, as well as making it clearer that the data needs to be 
fully declarative despite the ".rb".

If you mean for attribute files, I favor supporting Yaml there because it 
covers the 99% use case for people with a syntax they are slightly more 
likely to know. Ruby vs. Yaml on attribute files is super minor though, and 
I'm happy to agree to disagree and relocate that stuff out to a cookbook (I 
was planning on making a dialect-erbyaml cookbook anyway as a test case, so 
the incremental work here is super tiny). I think it will fall to me to put 
together some good documentation about what dialects exist and what use cases 
the work well for, and I'll have to keep that updated as time goes on and new 
dialects arise (I hope).

--Noah

> On Wed, Oct 2, 2013 at 2:18 PM, Noah Kantrowitz 
> <
 >
>  wrote:
> 
> On Oct 2, 2013, at 2:05 PM, Daniel DeLeo 
> <
 >
>  wrote:
> 
> > Chatted with the other folks at Opscode, and here's what we want to do
> >  (you can read this as a gist if the formatting is messed up: 
> > https://gist.github.com/danielsdeleo/18c4e4e2bba6eff922d4 ;):
> >
> > # Summary:
> >
> > * Yes to "tiny" cookbook layouts
> > * Yes to removing implicit filespecificity
> > * Yes to user-defined, explicit filespecificity
> > * Yes to modular, modifiable code that can support dialects
> > * No to including any dialects in core or supporting them beyond
> >   best-effort Open Source Community courtesy.
> 
> Which dialects do you mean in particular? Ruby support itself is now setup 
> as a dialect, so that one needs to be there. Beyond that I'm working on 
> expanding the dialect system to encompass the decoder dispatch for stuff 
> like metadata.{rb,json}, role files, and env files all of which will mean a 
> built-in JSON dialect in addition to the Ruby one. Then there is the JSON 
> and Yaml dialects I setup for attribute files, just to be clear I think you 
> are suggesting those should be relocated to external cookbooks?
> 
> --Noah
> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail