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


Chronological Thread 
  • From: Steven Danna < >
  • To: Adam Jacob < >
  • Cc: Noah Kantrowitz < >, Chef Dev < >
  • Subject: [chef-dev] Re: Re: Dialect support and loading enhancements
  • Date: Thu, 19 Sep 2013 16:42:50 -0700

Hi,

Overall, I'm +1 on 3, 4, and 5.  I'm unsure on 1 and 2.

> 1) Do other people actually think the directory structure of a cookbook is 
> the biggest barrier to learning? This confuses the crap out of me - but I'm 
> the one that inflicted the directory structure on you, so perhaps I'm an 
> awful judge.

It certainly isn't the biggest barrier to learning.  However, I have
helped more than a few people who were confused by this.  Also, in my
own cookbook writing, I'm using default 90% of the time.  Given how
rarely I use directories other than default, having the ability to
forgo it entirely and handle the other 10% of the cases via passing an
array to the source attribute would be nice.

Cheers,

Steven




On Thu, Sep 19, 2013 at 3:54 PM, Adam Jacob 
< >
 wrote:
> First off, thanks for thinking this through so well, and having the patch to
> match. Awesome.
>
> I have a couple of questions/statements/observations:
>
> 1) Do other people actually think the directory structure of a cookbook is
> the biggest barrier to learning? This confuses the crap out of me - but I'm
> the one that inflicted the directory structure on you, so perhaps I'm an
> awful judge.
>
> 2) It feels like this could be accepted in pieces, depending on how we all
> feel about it. For example, 3 and 4/5 are to separate features, and how I
> feel about them is totally not influenced by how I feel about dialects. It
> makes sense to me that 4/5 should be adopted - we cause more confusion with
> the single copy pattern than we do delight, and nobody looses out - it's
> easy enough to implement it if it turns out you need it.
>
> 3) My concern about dialects is really that, in the end, you wind up hitting
> a wall. In the grand tradition of manipulexity and whipuptude, we know there
> is a path that can provide both (the ruby dsl), but that we think there are
> some barriers to it's full whipuptidunal potential (too many directories,
> etc.) Is it really simpler to learn the syntax from yaml, and all the
> gotchas that might be implied there, than to learn the basic syntax that you
> know scales moving forward? I think ansible and salt both provide a
> delightful experience of immediacy to the consumer, and that experience is a
> great one to mimic - but I'm not sure I think that path is because you're
> writing YAML rather than ruby. Is this simply because I know more than one
> programming language and have no inherent fear of learning another one
> anymore?
>
> Best,
> Adam
>
>
> On Thu, Sep 19, 2013 at 1:37 PM, Noah Kantrowitz 
> < >
> wrote:
>>
>https://github.com/opscode/chef/pull/997
>>
>> At long last I've pushed up a completed-enough-to-use version of my
>> [dialects
>> proposal](https://gist.github.com/coderanger/a6e0c627d349f0712dcc). I won't
>> repeat the whole document here, but some highlights:
>>
>> 1. Hooks to load Chef recipes and attribute files from formats other than
>> .rb
>> 2. JSON and Yaml dialects for attribute files.
>> 3. Root shortcuts for cookbook source files of which you commonly have
>> only one.
>>     cookbooks/
>>       apache2/
>>         attributes.rb
>>         recipe.rb
>>         library.rb
>> 4. Removal of the need for the default/ path segment under files/ and
>> templates/.
>> 5. Ability to pass an array to #source on cookbook_file and template to
>> define your own lookup path similar to the current implicit one.
>>
>> Personally I think all of these put together are an order of magnitude
>> improvement in ease of learning Chef and writing new cookbooks while not
>> losing any of the expressive power you want on the high end. This branch
>> should present no backwards incompatibilities, though I think it should 
>> kick
>> off a discussion separately about deprecating the implicit search path on
>> files/ and templates/ in favor of people using the new explicit search path
>> syntax for the rare occasions where such things are desired (and even in
>> those cases, it is generally just a few of the options in the current 
>> search
>> path). Any such deprecation would have to be over a very long time though. 
>> I
>> have opened https://tickets.opscode.com/browse/CHEF-4559 to track this
>> patch. If anyone has any feedback please don't hesitate to shoot me an 
>> email
>> or comment on the pull request/ticket.
>>
>> --Noah
>>
>
>
>
> --
> Opscode, Inc.
> Adam Jacob, Chief Dev Officer
> T: (206) 619-7151 E: 
> 



Archive powered by MHonArc 2.6.16.

§