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

[Kevin Nuckolls < >]

I think maybe adding the maintainer_repo to the metadata, and making an additional optional field for the depends git url would be an adequate solution. The cookbook maintainer can set explicit dependencies to specific cookbooks on github. Librarian, Berkshelf, etc can be extended to take that optional parameter into account. 

It could be as simple as that. If you as the chef operator want to override some part of the dependency chain, just put a reference to the cookbook you want in your Cheffile / Berksfile.

On Thu, Nov 15, 2012 at 2:36 AM, Jesse Nelson < " target="_blank"> > wrote:

Kevin, 

I agree with your point here, and In  general I too try to encapsulate deps in roles, but the thing that brought this up for me was interfacing with a cookbook that had metadata librarian and berkshelf files. all calling out deps.  If I want to change that I should have single source of truth (with the ability for any of those to override IMO) for where these sources are from. I only started using depends when I started publishing cookbooks, and really when I started to leverage berkshelf for everyday management. 

maintainer_url  is great for pointing to where the cookbook came from, but I want to know where the cookbook author thinks the deps should resolve to. When I am making a cook I want to be able to provide it to people so they can use any tooling they like instead of just my opinions about how you should get this cooks deps.  If we had deps in meta call out sources then tools like librarian and berkshelf could "just work" without a needed Berksfile unless you wanted to override for whatever reason.

I guess I see the prevalence of cookbook management tools as a symptom to a problem everyone has, and one small step towards simplifying would be adding source metadata to depends. 

On Thu, Nov 15, 2012 at 4:42 PM, Kevin Nuckolls < " target="_blank"> > 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. 

Best Regards,

Kevin Nuckolls

  

On Wed, Nov 14, 2012 at 11:48 PM, Joshua Timberman < " target="_blank"> > wrote:

And metadata should have a "maintainer_repository" added. 

http://tickets.opscode.com/browse/CHEF-286

On Nov 14, 2012, at 22:27, "Noah Kantrowitz" < " target="_blank"> > wrote:

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to metadata ? This way berks/librarian/whisk/whatever tool can operate against the metadata, and cookbook makers don't have to worry much about the specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be put in the metadata. Just cruftiness that keeps them separate. Patches plz kthx!

--Noah