I’m totally +1 on features 4 and 5, though. Perhaps those should be
broken out into a separate PR?
I’ve read the discussion about dialects. I still don’t really buy the
arguments. Is this merely an optics thing, where people look at the
current attributes format and recoil in horror at the "programming"
they have to do? How does expressing those in JSON or YAML solve that
when they still have to “program” to write Chef recipes?
Sysadmins “program” all the time. We see nothing wrong with hacking up
some bash, Perl, sendmail.cf () to solve a problem. Call it
by another name if you like (“scripting”) but it’s still programming.
We shouldn’t add features to our software to solve a semantics
On Fri, Sep 20, 2013 at 11:38 AM, mandi walls email@example.com wrote:
Ha! I second that emotion.
On Friday, September 20, 2013, Sean OMeara wrote:
As someone who regularly has to train people in Chef, dialects scares the
living crap out of me.
On Thu, Sep 19, 2013 at 1:37 PM, Noah Kantrowitz firstname.lastname@example.org
At long last I’ve pushed up a completed-enough-to-use version of my
proposal. I won’t
repeat the whole document here, but some highlights:
- Hooks to load Chef recipes and attribute files from formats other than
- JSON and Yaml dialects for attribute files.
- Root shortcuts for cookbook source files of which you commonly have
- Removal of the need for the default/ path segment under files/ and
- Ability to pass an array to #source on cookbook_file and template to
define your own lookup path similar to the current implicit one.
[ Julian C. Dunn email@example.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]