[chef-dev] Re: Re: Re: CHEF-3762: LWRP DSL for subclassing needed?

[Noah Kantrowitz < >]

On Jan 28, 2013, at 3:11 PM, Daniel DeLeo wrote:

> 
> On Monday, January 28, 2013 at 3:06 PM, Noah Kantrowitz wrote:
> 
>> 
>> On Jan 28, 2013, at 2:45 PM, Bryan McLellan wrote:
>> 
>>> http://tickets.opscode.com/browse/CHEF-3762
>>> 
>>> There's been some talk about adding a DSL for subclassing LWRPs. I've 
>>> heard both sentiments that it would be useful and questions if it makes 
>>> something justifiably easier.
>>> 
>>> Can those promoting it make a case? Can anyone else soap box about their 
>>> own experience?
>> 
>> I've been pushing hard for this for a long time now. As some examples of 
>> places this would be directly useful, I've spent part of today reviewing a 
>> new Mercural resource/provider which has to subclass Chef::Resource::Scm 
>> and as such can't use the simpler LWRP syntax. Another example is any of 
>> the multitude of service resources which currently either duplicate code 
>> or use the "heavy" syntax. Beyond just subclassing built-in pieces, the 
>> application cookbook would gain a lot by allowing subclassing of 
>> individual sub-resources in places where things were mostly like a 
>> standard deployment but just need a little tweak, like (to use Django 
>> examples because that is what I'm familiar with) a requirements.txt in a 
>> non-standard place, or setting up the database connection a little 
>> differently. This would allow much more fine-grained overriding than is 
>> possible right now within the bounds of the LWRP system, and hopefully 
>> would reduce the number of times people copy-paste-fork parts of upstream 
>> cookbooks. In my bright and glorious LWRP-ified future this will only get 
>> more important over time, as I hope more cookbooks use LWRPs to provide 
>> internal modularity like this, just as you would see in any other OO API.
>> 
>> --Noah
> Once you know about subclassing and so on, is it really that onerous to use 
> the "heavy" syntax?
> 
>     class FooProvider < Chef::Provider::Scm
>     end
> 
> ...doesn't seem like a ton of work.

Helpers like #attribute and #action don't work in non-LWRP files as far as I 
know. More to the point it confuses people seeing "heavy" resource and 
providers living under libraries/, so I think we should try to minimize the 
need for them. Additionally is there any negative to this change? It makes 
LWRPs more flexible without adding complexity unless you specifically request 
it as an author. Those that don't want to subclass things can just ignore the 
new functionality entirely.

--Noah

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