Chef Devs,
Most of the questions I've seen in IRC from newcomers relate to Chef's conceptual model: compile/converge, attribute precedences, what to do with data-bags, etc. I haven't seen enough clear high-level guidance from Opscode on these questions.
There is certainly a decent share of Ruby syntax questions. But it does not strike me as the category most in need of work. And adding more syntaxes strikes me as introducing more conceptual complexity while reducing documentational clarity for most newcomers.
Host-specific & platform-specific cookbook-files/templates: This can be accomplished with either (1) #source taking an array and offering a helper method #expand_source (or some other name) to expand a name into a combination of host-specific and platform-specific sources, or (2) adding an attribute #expand_source (or some other name) to the cookbook-file/template resources.
Dialects in attributes files: This is not necessarily a lot of repetition when done in Ruby. The #default, #default_unless, #override, #override_unless methods may be extended to accept an optional hash argument so that it can be passed a nested hash literal. This syntax would be very close to whatever could be achieved with JSON and is in fact very close to what one already does with Ruby roles (example from opscode-cookbooks/apt):
default({
"apt" => {
"cacher-client" => {
"restrict_environment" => false,
},
"cacher_dir" => "/var/cache/apt-cacher-ng",
# ...
},
})
If one wanted YAML, one could even do it with just a touch of boilerplate (example from opscode-cookbooks/apt):
default YAML.load(<<-ATTRIBUTES)
apt:
cacher-client:
restrict_environment: false
cacher_dir: /var/cache/apt-cacher-ng
# ...
ATTRIBUTES
Cheers,
Jay Feldblum