[chef-dev] Re: Re: Re: Re: Add "url" to depends/metadata ?

[Noah Kantrowitz < >]

On Nov 14, 2012, at 11:42 PM, Kevin Nuckolls wrote:

> I've always thought that include_recipe is an anti-pattern if you're 
> including recipes outside of the cookbook you're in. It introduces coupling 
> that's too vague since anyone can download a cookbook of the same name and 
> upload it to the chef server. It may or may not have been the specific 
> dependency cookbook the author intended it to be. Case in point, there are 
> a couple cookbooks floating around out there in the wild with the exact 
> same name, 'nodejs'. There are multiple statsd cookbooks that appear to 
> include_recipe 'nodejs' except they actually mean to refer to different 
> implementations. (As a disclaimer it's late and that's just an example I 
> remember running into previously when working with third party cookbooks. 
> I'd have to go find the specific repos to prove that this example exists in 
> the wild.)
> 
> All over the opscode cookbooks this pattern is used, with the implicit 
> understanding that these couplings are between the opscode cookbooks of 
> these names. It seems to be alright if I stay within the confines of 
> github.com/opscode-cookbooks, but once you start to pull in cookbooks on 
> the community site that weren't created / condoned by opscode or from some 
> stranger's git repo then you may not have any context as to which specific 
> cookbook implementation they meant to call via the include_recipe function. 
> So yes, I'm all for stronger specificity in dependency management between 
> cookbooks. 
> 
> Maintainer_repo as a url within the metadata.rb is a good idea. But I think 
> the depends statement should take a git/url parameter so the dependency 
> chain is more explicit and less reliant on context and naming. The only 
> downside of this is what do I do if I intend to intentionally alter the 
> dependency chain by pointing to my fork of an opscode cookbook because I've 
> fixed some bug that's relevant to my work and hasn't been merged in yet. I 
> wouldn't say I have a good solution for that.
> 
> All this to say, I've kind of written off include_recipe as taboo on our 
> team. I tend to subscribe more heavily to the philosophy that every 
> cookbook should have corresponding role or roles that explicitly 
> encapsulates it's dependencies. That gives you two things, one is that when 
> people need to pull together new nodes, they only need to compose their 
> runlists out of roles. Since those roles encapsulate all of their 
> dependencies by convention then the operator need not be familiar with all 
> the peculiarities of the naming of the underlying cookbooks and their 
> implicit couplings. The second is that at a glance you can see exactly 
> what's going to be installed on a node by inspecting the roles.
> 
> I adopted this pattern of using roles and eschewing metadata.rb's depends & 
> include_recipe because of the growing pains I had trying to figure all of 
> this out during my first year with Chef. I learned through a fair amount of 
> trial and error to try to stick within the confines of opscode-cookbooks, 
> and if I didn't then i should rgrep for include_recipe in any third party 
> cookbook to see if I'm likely going to end up with some dependency headache 
> down the line. I guess the only reason I wrote out this little epic was 
> just to highlight some growing pains I had with chef pertaining to this 
> topic and to mention the coping mechanisms I've had to adopt that appear to 
> fly in the face of conventional wisdom within the community. 

What you describe is a much deeper change to how chef works and is not really 
relevant to the question of fixing cookbook metadata so there aren't magic 
fields only the community site  knows about. Thank you for the ideas though.

--Noah