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
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
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.
On Wed, Nov 14, 2012 at 11:48 PM, Joshua Timberman email@example.com:
And metadata should have a “maintainer_repository” added.
On Nov 14, 2012, at 22:27, “Noah Kantrowitz” firstname.lastname@example.org 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