Issue #5517 has been updated by John Bollinger.
Luke Kanies wrote: > John Bollinger wrote: > > > > > > Do you mean *any* class that hasn't yet been evaluated, or do you mean the > > class to which the variable belongs? If the latter, then you are creating > > a new failure scenario. > > I just mean the one to which it belongs. > > And note that I don't ever mean that we'd parse classes that haven't been > parsed yet, just evaluate class objects that are sitting around unevaluated. > It's a much better form of lazy evaluation than we do right now, which just > has us waiting to do any evaluation until we've run out of other stuff to do. It's not clear to me exactly where the separation between parsing and evaluation lies, but I don't think it's possible to construct a scheme that ensures all class variable references that are now allowed continue to work, while at the same time deferring binding of parameter values to classes until late enough that class parameter overrides work reliably. (And this ignores defined() and any similar features that are parse- and/or evaluation-order dependent.) Think about the extreme case: what's to prevent a class parameter override being the very last thing evaluated (which must fail)? Lazy class evaluation only solves the problem if class parameter overrides are reliably evaluated before the classes whose parameters are overridden. But variable references are associated with the overridden classes, not with the overrides. Thus, although this approach to lazy evaluation might successfully defer some classes' evaluation longer or more intelligently than now happens, it cannot guarantee anything about when class parameter overrides are evaluated. Although it might be useful in its own right, it doesn't solve the problem at hand. ---------------------------------------- Bug #5517: behavior change within 2.6 makes it impossible to override class parameters of "included" parametrized classes https://projects.puppetlabs.com/issues/5517#change-83654 Author: Peter Meier Status: Accepted Priority: High Assignee: eric sorenson Category: language Target version: 3.x Affected Puppet version: 3.0.2 Keywords: parameterized_classes Branch: In 2.6.1 the following recipe: <pre> class a( $b_c = { 'b' => 'foo' } ) { notice $a::b_c if $a::b_c { notice $a::b_c['b'] } } class b { class{'a': b_c => false } } class b::c inherits b { Class['a']{ b_c => { 'b' => 'bleh' } } } class b::d { include ::b::c } include b::d </pre> produces the following output: <pre> $ puppet foo.pp notice: Scope(Class[A]): bbleh notice: Scope(Class[A]): bleh </pre> Which is what I expected. However with 2.6.3 it produces the following output: <pre> # puppet foo.pp notice: Scope(Class[A]): false </pre> Imho likely the changes for #4778 and #5074 are responsible for that behavior change. However this makes it impossible to overwrite parameters of a "included" parametrized class in a subclass. There are only ugly workarounds for that problem and I think this should actually work as it did within 2.6.1. Otherwise the usefulness of parametrized classes is quite reduced. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
