On Monday, June 2, 2014 11:04:01 AM UTC-5, Trevor Vaughan wrote: > > Just checking in. Does anyone else have any ideas on this one? > > I've tried everything obvious that I could think of and I'm coming up > blank. > >
I found some possibly-relevant information here: http://makandracards.com/makandra/14229-the-many-gotchas-of-ruby-class-variables. One of the details that strikes me as more important is that a reference to a class variable is bound at parse time, based on the lexical scope in which it appears (my paraphrase). In particular, the class_eval and instance_eval functions do not, the article claims, affect the scope with respect to which the variable is interpreted, and its appearance within the block passed to one of those functions is what triggers the warning, or at least one thing that can trigger it. (Note also the author's summary: "TLDR: Ruby class variables (@@foo) are dangerous in many ways. You should avoid them at all cost.") I think that means your class variable may not belong to the class to which you think it does. Since the whole point here is to have a data repository that multiple provider instances can share, can you not open a Puppet class whose instances are accessible and have appropriate duration, and add one as an instance variable? I had at one point suggested that the perhaps Puppet::Transaction should offer such a capability, and indeed, tying the data to a single transaction would problems with data being held over from run to run in daemon mode. It sounds good to me, anyway, but I'm afraid the implementation details are beyond my current knowledge of Puppet internals. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2dbe06ee-9867-4da4-a6c8-71e92d61c94d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
