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

[Mike < >]

One minor note on yaml:

We use this for config files with our customer-facing code, and the yaml syntax spacing issues border on nightmarish.

Given a choice to go back and change it, I don't know if we'd make a different choice, but a fair amount of customer support time is spent on debugging incorrect config file syntax.

I still don't know if I understand the reasoning behind the desire for _more_ config file syntaxes? Let's toss in TOML while we're at it as well?

-M

On Wed, Oct 2, 2013 at 6:15 PM, Noah Kantrowitz < " target="_blank"> > wrote:

On Oct 2, 2013, at 3:09 PM, Noah Kantrowitz < "> > wrote:

>
> 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).

Just to add a bit to this, I think some of my worry is that internally Chef will have JSON dialect support for a few objects (metadata, roles, envs, data bags) but attributes are kiiiiind of a special case in that you need an external cookbook. Will need to figure out how to explain that difference.

--Noah