[chef] Re: Re: Re: Re: Re: Re: Re: Re: delayed evaluation?

[Ranjib Dey < >]

you are right , when you pass a block inside a ruby_block resource's block attribute, its not invoked during the compile phase (unless you do run_action(:run) hacks). The challenge is how you capture this computed value and pass it back to another resource. node.run_state is one way of doing it. but again this is hacky. Also when reusing the coputed value you have to ensure the consumer ruby code is also evaluated in the execution phase, not it compile phase. i.e. another ruby_block resource where the block parameter is accessing node.run_state will work, but file resource's content attribute is evaluated during compile time , even if you do content node.run_state[:value_from_other_ruby_blockl], you are accessing a value that is not computed yet.

look this is hacky, but this will work:

ruby_block "foo" do

 block do

 node.run_state[:troll] = `ls /tmp`

end

end.run_action(:run)

file "/etc/bar" do

  content node.run_state[:troll]

end

i think use cases like this shows that we really dont have tow independent resources, rather they are coupled where one of them is dependent on other's attribute value. hence it might be worth to cleanly implement it in an lwrp where.

On Wed, Dec 18, 2013 at 4:10 PM, John Alberts < " target="_blank"> > wrote:

On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell < " target="_blank"> > wrote:

Isn't the issue only that %x[ls /tmp] is being evaluated at compile time?  Avoid that notation and you'll be able to do what you intend.  Use "system" instead and it will be evaluated as part of the ruby block.

I thought any ruby code inside a ruby block will not be evaluated during compile time and instead during the normal order of the execution phase.  I haven't tested this yet, but does it really matter if inside that ruby block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?

--
John Alberts