Unfortunately, I don’t have a specific example, but I know I’ve come across cases where I have to pass the node object from a recipe into a library method because the library didn’t know about the node object itself. I believe the differences come into play when you create a proper library using ruby modules (as in Julian’s post) vs. just adding helper methods with no namespacing.
"Should you": that's an architectural question for our developers,
presumably. You're right -- I usually pass either the node object itself or
the attributes thereof to a helper, if I need them:
Unfortunately, I don’t have a specific example, but I know I’ve come
across cases where I have to pass the node object from a recipe into a
library method because the library didn’t know about the node object
itself. I believe the differences come into play when you create a proper
library using ruby modules (as in Julian’s post) vs. just adding helper
methods with no namespacing.
On Friday, May 16, 2014 at 7:34 AM, Julian C. Dunn wrote:
"Should you": that's an architectural question for our developers, presumably. You're right -- I usually pass either the node object itself or the attributes thereof to a helper, if I need them:
Julian
The difference with library files is that they’re 100% plain ruby, evaluated in the context of the top level ruby environment (the TOPLEVEL_BINDING object) so there is no architecturally sound way for Chef to hook into them and add additional context (e.g., access to the node object). By comparison, other file types, such as recipes, attributes, and LWRPs, are evaluated in the context of an object that chef initializes for you, so chef can internally set variables (node, run_context, etc.) before handing control over to your code.
On Fri, May 16, 2014 at 10:31 AM, Daniel DeLeo dan@kallistec.com
wrote:
On Friday, May 16, 2014 at 7:34 AM, Julian C. Dunn wrote:
"Should you": that's an architectural question for our developers,
presumably. You're right -- I usually pass either the node object
itself or the attributes thereof to a helper, if I need them:
[...]
The difference with library files is that they’re 100% plain ruby,
evaluated in the context of the top level ruby environment (the
TOPLEVEL_BINDING object) so there is no architecturally sound way for
Chef to hook into them and add additional context (e.g., access to
the node object). By comparison, other file types, such as recipes,
attributes, and LWRPs, are evaluated in the context of an object that
chef initializes for you, so chef can internally set variables (node,
run_context, etc.) before handing control over to your code.
This behavior allows for some very interesting things we can do to Chef
from cookbooks.
Yup -- you can monkeypatch anything in Chef itself from a library.
Good: You can experiment with patches to core without having to modify
the client. (q.v. chef-metal, chef-elevate, others)
Bad: You can blow your foot clean off super easily.
