----- Original Message -----
> From: "Andrew Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> Sent: Thursday, April 19, 2012 9:43:36 PM
> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>
>
> On Apr 19, 2012, at 1:28 PM, R.I.Pienaar wrote:
>
> >
> >
> > ----- Original Message -----
> >> From: "Andrew Parker" <a...@puppetlabs.com>
> >> To: puppet-dev@googlegroups.com
> >> Sent: Thursday, April 19, 2012 8:42:33 PM
> >> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
> >>
> >> I've got a branch of puppet that has dynamic scoping removed.
> >> Considering the impact that this will have on things and my
> >> personal
> >> uncertainty about whether people will still be able to achieve
> >> everything they want to with puppet, I'd really like to get people
> >> to grab it and try it out.
> >>
> >> https://github.com/zaphod42/puppet/tree/feature/13970/remove-dynamic-scoping
> >
> > This Just Works for me, but I've deliberately never had any dynamic
> > lookup
> > in my code as I've always used extlookup/hiera to avoid this
> > problem so thats
> > not a surprise, someone else will need to test with more broken
> > manifests :P
> >
>
> Yeah, I expect that this will bite people a lot more who didn't
> religiously hold themselves to certain patterns.
>
> > So I am guessing the thing that would happen is variables that were
> > previously
> > filled in would be undef without dynamic scope or what would be the
> > the exact
> > effects of this?
> >
>
> Good question, it should be undef, but I'll add a test for that. In
> fact I'll take all of the old tests for the old dynamic behavior and
> update them for what should happen now.
there's been a recurring question about a strict mode for puppet - so that
it will, when enabled, cause a compile failure when you try to read a undef
variable ie. "foo-${bar}" would compile fail if bar is undefined.
This seems like something that might help a lot in catching problems if indeed
the behaviour is as you say above
>
> > Do you have sample code showing what worked before and failed
> > after? and how
> > would that failure/change in behaviour manifest?
> >
>
> That is something that we'll need to put together so that there is
> clear documentation about what changes are going to be needed to be
> made in the new system. As a first pass, the test cases should
> cover those situations.
>
> >>
> >> On Apr 19, 2012, at 11:45 AM, R.I.Pienaar wrote:
> >>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Andrew Parker" <a...@puppetlabs.com>
> >>>> To: puppet-dev@googlegroups.com
> >>>> Sent: Thursday, April 19, 2012 7:16:40 PM
> >>>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
> >>>>
> >>>>
> >>>> On Apr 19, 2012, at 9:38 AM, R.I.Pienaar wrote:
> >>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Andrew Parker" <a...@puppetlabs.com>
> >>>>>> To: puppet-dev@googlegroups.com
> >>>>>> Sent: Thursday, April 19, 2012 5:30:29 PM
> >>>>>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
> >>>>>>
> >>>>>> Absolutely. Debugging is always made fiendishly difficult when
> >>>>>> there
> >>>>>> is "action at a distance" stuff going on. Limiting that kind
> >>>>>> of
> >>>>>> interaction is why globals are frowned upon in most
> >>>>>> programming.
> >>>>>> Is
> >>>>>> there a lot of use of globals (topscope) other than facts (and
> >>>>>> enc
> >>>>>> parameters, I guess) in puppet?
> >>>>>>
> >>>>>
> >>>>> Today there is a lot of it going around. The bulk of modules
> >>>>> would
> >>>>> be
> >>>>> written with something like:
> >>>>>
> >>>>> class foo::install {
> >>>>> if $foo_version { $version = $foo_version } else { $version =
> >>>>> "present"}
> >>>>>
> >>>>> package{"foo": ensure => $version}
> >>>>> }
> >>>>>
> >>>>> and then people will "configure" these modules either in
> >>>>> site.pp
> >>>>> with
> >>>>> globals or in a node with node scope variables.
> >>>>>
> >>>>> node "blah" {
> >>>>> $foo_version = "1.2.3"
> >>>>>
> >>>>> include foo::install
> >>>>> }
> >>>>>
> >>>>> This is very common, it used to be the only real option outside
> >>>>> of
> >>>>> using
> >>>>> extlookup and hiera. And there are vast amounts of code out in
> >>>>> the
> >>>>> real
> >>>>> world and on the forge built around this pattern.
> >>>>>
> >>>>> worse, you also had:
> >>>>>
> >>>>> class someother {
> >>>>> $foo_version = "1.2.4"
> >>>>>
> >>>>> include foo::install
> >>>>> }
> >>>>>
> >>>>> and so depending on the parse order of the actual include lines
> >>>>> the
> >>>>> outcome
> >>>>> might be different in the end, this being at the whim of the
> >>>>> autoloader and
> >>>>> such it was a bit tricksy.
> >>>>>
> >>>>> All of this code either needs big refactors or just doesnt work
> >>>>> with 2.7.
> >>>>>
> >>>>
> >>>> Thanks for these examples, they help on lot in my understanding
> >>>> of
> >>>> common patterns (I hope at some point to go through code on the
> >>>> forge and try to get some more understanding).
> >>>>
> >>>> Since I'm not entirely clear on all the changes from 2.7 to 2.6,
> >>>> what
> >>>> changed to make these things stop working in 2.7? From my
> >>>> understanding of the 2.7 variable lookup system it seems like
> >>>> they
> >>>> should work in 2.7.
> >>>
> >>> My examples isnt showing the particular bug I was thinking about
> >>> -
> >>> I
> >>> will need to go dig through IRC logs to find the particulars.
> >>>
> >>> However in the above examples accessing $foo_version would log a
> >>> deprecation
> >>> warning saying you must use fully qualified variable path. But
> >>> for
> >>> node
> >>> variables there is no fully qualified variable path so you're
> >>> just
> >>> stuck
> >>> and forced to make peace with a all the warnings since there's no
> >>> non
> >>> param classes way to fix that. This is less drastic than 'doesnt
> >>> work' but
> >>> for many its unacceptable either way as no clear way exist to fix
> >>> this dire
> >>> warning of impending future doom:
> >>>
> >>> warning: Dynamic lookup of $nodevar at /home/rip/test.pp:4 is
> >>> deprecated.
> >>> Support will be removed in Puppet 2.8. Use a fully-qualified
> >>> variable name
> >>> (e.g., $classname::variable) or parameterized classes.
> >>>
> >>> The proposal that started this thread is about that but I believe
> >>> its the
> >>> wrong way, we need a node scope so people can address node scope
> >>> variables
> >>> different from top scope variables (what will happen if in a node
> >>> I
> >>> set the
> >>> value of a fact if node scope vars become top scope vars?)
> >>>
> >>> And we're suggesting rather than new and wonderful ways to
> >>> address
> >>> scopes
> >>> ie $::topscopevar lets just use hashes.
> >>>
> >>> In puppet code we'd have:
> >>>
> >>> $facts["operatingsystem"]
> >>>
> >>> in templates we'd have:
> >>>
> >>> @facts["operatingsystem"]
> >>>
> >>> all nice and simple vs the current situation of
> >>> $::operatingsystem
> >>> vs
> >>> scope.lookupvar("::operatingsystem")
> >>>
> >>>>
> >>>>> Until there is wide adoption of param classes or some data
> >>>>> system
> >>>>> this
> >>>>> will unfortunately still be the way.
> >>>>>
> >>>>> The proposed hash like syntax will make for much lighter
> >>>>> refactoring apart
> >>>>> from all the other gains expressed in that ticket.
> >>>>>
> >>>>
> >>>> Is the main thing standing in the way of param class adoption
> >>>> the
> >>>> changes that you referenced above that are keeping people moving
> >>>> to
> >>>> 2.7? Or are they in some way inadequate (Jo mentions this in his
> >>>> email)?
> >>>
> >>> I think a capable data system is required to make param classes
> >>> viable, whats
> >>> wrong with them would be an entirely different thread (of which I
> >>> think there
> >>> are several in the list archives probably approaching 100s of
> >>> messages :P)
> >>>
> >>> --
> >>> You received this message because you are subscribed to the
> >>> Google
> >>> Groups "Puppet Developers" group.
> >>> To post to this group, send email to puppet-dev@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> puppet-dev+unsubscr...@googlegroups.com.
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/puppet-dev?hl=en.
> >>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Puppet Developers" group.
> >> To post to this group, send email to puppet-dev@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> puppet-dev+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/puppet-dev?hl=en.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Puppet Developers" group.
> > To post to this group, send email to puppet-dev@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-dev+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-dev?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
