Issue #1565 has been updated by James Shubin.
@Timur Thank you for your prompt reply. bar is actually a variable name used inside the foo class. I'll be continuing my development on this project with the hopes that this bug gets fixed, since my design relies on this. :) I'll be posting all of my code in the coming months, so hopefully this will provide another solid use case of this functionality too. Puppet devs please let me know if you'd like me to test this or otherwise as ready. Thanks, James ---------------------------------------- Bug #1565: puppet parser not order independant https://projects.puppetlabs.com/issues/1565#change-74557 Author: Ryan McBride Status: Accepted Priority: Normal Assignee: Category: language Target version: 3.x Affected Puppet version: 0.22.1 Keywords: Branch: The puppet parser has number of issues regarding order-of evaluation: * It does not always ensure that included classes are evaluated before qualified variables referring to them are evaluated. ([[LanguageTutorial#qualified-variables]]) * It may evaluate classes before the scope in which they are defined is evaluated. * the defined() function is "unfortunately dependent on the parse order of the configuration when testing whether a resource is defined." ([[FunctionReference#defined]]) As far as I understand it, the intent is that puppet is a declarative language, in which order of evaluation should not matter, and it would be nice to have these issues cleared up. Conversely, if puppet continues to be "somewhat order dependant", stronger mechanisms to provide control over order-of-execution or at least make order-of-execution more predictable are necessary. I believe the former is preferable. The following example demonstrates the first two of these problems (tested on both 0.24.5 and HEAD): <pre> ###################################### # define some classes class apache { apache_setup { "config" : } } define apache_setup ( $chroot = true, $ssl = false ) { # sanity checking, platform-specific defaults $_chroot = $chroot $_ssl = $ssl class apache_config { $ssl = $_ssl $chroot = $_chroot # more variables here } include apache_config # actuall apache setup goes here } class trac { case $apache_config::chroot { true: { notice("chroot = true") # do something } default: { # do something else notice("chroot = ${apache_config::chroot}") } } } ###################################### # Now use what we've set up class apache_ssl inherits apache { # override the defaults Apache_setup["config"] { ssl => true, chroot => false } } include apache_ssl #include apache_config include trac </pre> If this example is executed as-is, we recieve the error, it has clearly been included in apache_setup. (issue 1 above) <pre> Class apache_config has not been evaluated so its variables cannot be referenced at /tmp/foo:26 on node 000AE43B1909 </pre> If we uncomment the 'include apache_config' directive at the bottom of the example to ensure that puppet sees the class as being included, puppet evaluates apache_config _before_ the apache class and apache_setup define; the scope in which apache_config is defined is not evaluated, and the variables it depends on are evaluated as empty strings. (issue 2 above) <pre> notice: Scope(Class[trac]): chroot = </pre> -- 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 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-bugs?hl=en.
