Help debugging Ruby 2.0 issue

[Trevor Vaughan]

All,

Some of you may recall that I posted the following in the past as a method for keeping data synchronized between individual resource declarations in Puppet and applying things once all of them are complete

https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/.

However, I've run into a bit of an issue with Ruby 2 in that I can't determine the proper method for keeping this technique properly functional and getting rid of the following warning "warning: class variable access from toplevel".

This is generated each and every time that I access a class variable and I'm not quite sure what the correct technique is for fixing the code.

Any pointers would be appreciated.

Thanks,

Trevor

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Felix Frank]

On 05/27/2014 06:05 PM, Trevor Vaughan wrote:
> https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/.
>
> However, I've run into a bit of an issue with Ruby 2 in that I can't
> determine the proper method for keeping this technique properly
> functional and getting rid of the following warning "warning: class
> variable access from toplevel".
>
> This is generated each and every time that I access a class variable and
> I'm not quite sure what the correct technique is for fixing the code.

I'll be honest - the whole scoping in Ruby is pretty mysterious to me at
times.

If I understood and remember correctly, @@ only does what you need when
used inside instance methods. In class methods or outside of methods, it
would actually refer a member of the class's class (which is Class? or
something...), so it's only @ for the declaration at class scope.

Again, I may be totally on the wrong track.

Best,
Felix

[Trevor Vaughan]

Thanks Felix,

Usually, in this case, I could create a Module and just mix it in. Unfortunately, I can't find the correct magic to make this work inside of a provider.

The @@ is doing what I want it to, even in 2.0, but there's just no way that I can find to get the warnings to go away.

Interestingly, the only "approved" way to use class variables is the one that I'm using it for, to save cross-instance configuration state.

It might take hacking the Puppet source directly and, if that's the case, might as well just stuff in a class-based state management system to make all of this easy to do.

Thanks,

Trevor

--
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 puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5384BA0D.5000803%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Trevor Vaughan]

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.

Thanks,

Trevor

[John Bollinger]

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

[Trevor Vaughan]

Thanks John,

Unfortunately, the internals are above my current understanding as well. But, yes, your ideas and explanation make sense and I had hit that site before.

I'm not exactly sure what my class variable belongs to but I do know that I couldn't figure out another sane way of sharing state between all of the instances.

Still crossing my fingers that something better comes along.

I could fall back to doing what datacat does and spawning another resource just for the purpose of building this one, but that doesn't really seem better.

Thanks,

Trevor

--
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 puppet-dev+...@googlegroups.com.

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.