On Oct 8, 2010, at 10:53 AM, Paul Berry wrote:
> Nick and I had a discussion about variable scoping yesterday, and we've come
> up with a plan to get rid of the confusing aspects of variable scoping and
> resource defaults in the long term, without putting an undue short term
> burden on users to rework all their manifests. The plan is based around the
> idea of getting rid of dynamic scoping in the long run, but giving users a
> grace period during which dynamic scoping still works, so that they can
> gradually transition their manifests to using parameterized classes instead
> of dynamic scoping:
>
> 1. Fix tickets 4534, 4778, and 4427. These are the tickets that are
> preventing people from being able to use parameterized classes effectively
> now. If possible, fix them in the 2.6.x branch so that the fixes will be
> released in 2.6.3 and people can start using parameterized classes ASAP.
>
> 2. Add a warning to 2.7 that lets people know if when their manifests are
> relying on dynamic scoping (and hence will break once we switch to lexical
> scoping). This will give users a chance to transition their manifests
> gradually over to using parameterized classes where they used to use lexical
> scoping. It also gives us all time to figure out whether there are any other
> things we were using dynamic scoping for that can't be easily accomplished
> using parameterized classes.
Markus is definitely right about this - there's a serious risk of log-spamming,
and we've gotten big complaints about it in this kind of area in the past.
> 3. Add an option to 2.7 that lets users switch from dynamic to lexical
> scoping once they have taken care of all their warnings.
>
> 4. In 2.8, assuming we haven't discovered any showstopping reasons to keep
> dynamic scoping, eliminate the option so that Puppet always uses lexical
> scoping.
Overall seems like a good plan. My only concern is that we'd have to work
*really* hard on documentation and communication, and:
The big concern about switching to lexical scoping was resource defaults,
wasn't it? I think we determined in the end that the defaults just need to be
global for most cases anyway, but it's at least something to think about. It
might require that we support an 'extend'-like concept, where you can pull
defaults (and maybe variables) from one class into another:
class mydefaults {
File { owner => root }
}
class mystuff {
extend mydefaults
}
This might make it so we don't need dynamic scoping for defaults. But I might
be wrong about Nigel's concerns.
--
I think that's how Chicago got started. A bunch of people in New York
said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't
cold enough. Let's go west.' --Richard Jeni
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
