[chef] Re: Re: Re: Re: Re: Re: good example of chef definitions ? need help with issue below

[Daniel DeLeo < >]

On Saturday, October 5, 2013 at 12:17 AM, Ranjib Dey wrote:

the providers can always introspect loaded recipes and raise an error if its absent. you can have a convention that "to use the lwrp you have to include the default recipe of the same cookbook". but the fact that you will be able to chain it those lwrp into other lwrp is immense. definitions has been particularly been painful to extend.  take any community cookbook and start extending it, u'll realize cookbooks that give definitions are particularly trouble some, cause you cant predict their behavior in nested environments. use_inline_resource has been a blessing :-) , i really cant think of a compelling reason to use definition now (post chef 11)  unless you run really old chef . i 'll be very interested to know what others think?   

Many people have expressed a desire to make their LWRPs "just work" and have gone through a lot of contortions to make `include_recipe` work inside a LWRP. This results an awkward mixing of compile and converge phase, requiring even more contortions. I think the best thing to do in this case is to provide _both_ a definition and a LWRP. All of the logic goes in the LWRP, and the definition is the "easy mode" interface that does `include_recipe` and then calls the LWRP. If you do this, you can guarantee that whatever prerequisites the LWRP requires are installed before it runs, the prerequisite recipe only runs once (this is a problem with some of the hacks people use to `include_recipe` inside LWRPS), the user can switch from the definition to the LWRP if they want to use a different recipe to install the prereqs, and the LWRP can be reused in other LWRPs if desired.

This example (and Lamont's example previously) are examples of the value of adding arbitrary compile time logic to recipes. The problem is that the language of resource definitions (reinforced by the examples in the docs) fit a totally different use case than what definitions turned out to be good for. Also, LWRPs can be not-lightweight-enough for some users, so they turn to definitions which look a little easier to get started with. Both of these issues could use some attention.

-- 

Daniel DeLeo