On Apr 18, 2012, at 4:04 PM, Andrew Parker wrote:
>> On Apr 17, 2012, at 9:00 AM, Andrew Parker wrote:
>>> Has anyone seen something where a manifest used $::var in order to *not*
>>> get the value of $var that is overridden in a node?
>>
>> Uh… I use it extensively.
>
> Ah, interesting. Could you provide some examples of what you use it for?
Not offhand, sorry, used it a lot at $formeremployer. Building up new stuff
for $currentemployer and have no examples handy. But I really running into that
'feature' and going OH! and using it to solve a few problems.
> The bad thing (under the new system) is that node is a special citizen that
> gets to have dynamic scoping, but nothing else does.
No, I don't want dynamic scoping. But I want node-level scoping distinct from
top-level scoping. I don't want them flattened.
> If node was not its own scope and instead was just part of top scope, then
> the rules for where a variable comes from turns into "in the class, the
> parent(s), or the topscope".
>
> If node is its own scope that is given special dynamic lookup status, then
> your rules are "in the class, the parent(s), whatever node included the
> class".
>
> In both cases there is the additional complication of node inheritance which
> makes it even harder to figure out what value you are actually going to end
> up with.
Honestly, everything you just described is why puppet is confusing to code. I
find it much easier to be explicit in all of my calls, so that you know. The
worst bit of modifying a puppet class is finding a variable and not knowing if
it's global or local or inherited, and searching around to figure it out. Or
causing a syntax parsing error because a variable name you tried to use is
already defined, and it's not defined in the class you are operating on -- it's
in a completely different file potentially not even checked out by you at the
time.
If I want a top-level variable, I'll ask for one. If I want a node-level
variable, I'd like to be able to ask for one (which I can't today afaik). I
never want either of them unless I ask for them by name.
>> In fact, I'd prefer stricter lexical scoping rather than vaguer. I believe
>> that the current situation is what confuses everyone, and that if
>> referencing something out of scope was ALWAYS explicit that would be
>> preferred. I'd also prefer tighter scoping around each node -- I could
>> simplify a lot of code if this worked better, such that I could use node
>> variables within parameterized classes easily, always being set for the node
>> currently being operated on.
>
> Do you mean having no nesting of scopes at all (i.e. everything is local and
> there is no lookup outside of the scope)? That would mean a lot more verbose
> manifests but is a possible option.
Yes, I do. Or an option to enable that at least. I realize that many people
love a big swash of global variables, so I'm going against the stream. In fact,
I would appear to be going against the grain of ruby itself. But sometime after
your module repository breaks 20k lines of code you really want to strangle
something every time you get a variable collision you never intended inside
what should be a tight a lexical scope.
> Could you elaborate on what you mean by tighter scoping around the node? An
> example of what that might look like, perhaps?
One thing I'm referring to (which might have changed recently, but was using
2.6 exclusively at $formerjob) was that if I used parameterized classes I was
unable to access node variables except by passing them in. This wasn't always
possible due to limited return values/limited syntax. This led to us using a
blend of parameterized classes and included classes, and that really was
insanity to manage. I'd like to go to 100% parameterized but that's hard to do
when you can't explicitly reach for node-level variables.
I'm not proposing syntax here, I'm showing what I mean.
$var is always local to the current scope
$::toplevelvar is top level var
$node::nodevar
$class::classvar
Again, that's not a syntax suggestion just showing that I want to be able to
grab for these things individually and distinctly.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other
randomness
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
