Issue #11915 has been updated by Ben Hughes.
> Technically, `$::` is "less special", in that it treats them like any other > variable. I think that is a mistake because they are actually much more > special than other variables, if for no other reason than they come from a > special source. (The syntax obviously also removes the clash of names > between variables and facts, because `$foo` and `%foo` or distinct > entities...) Yes, I know technically it's just a variable, but I was meaning special in teh sense of "looks ugly and not just like a normal dollar variable". > I am much less afraid of complaints that we are changing syntax than > complaints we are making everyone type three, or five, extra characters > without substantial gains. > I appreciate the feedback, though, on how this hangs together. I think a symbol such as @ or % for facts would be far nicer than putting it as part of some hash. Seeing as they're going to be commonly used. In ERB templates would they all still be referenced the same? How will that deal with the possible name clashes? ---------------------------------------- Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes https://projects.puppetlabs.com/issues/11915#change-54948 Author: Brice Figureau Status: Needs Decision Priority: Normal Assignee: Randall Hansen Category: language Target version: Affected Puppet version: 2.7.9 Keywords: scope facts lookup hash Branch: Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is: * confusing for new users * prone to name-clashing Those variables are really specific in Puppet because they come from the exterior. My proposal would be to move them to separate Puppet hashes of names: * `$facts` * `$server_facts` * `$parameters` So usage would be: <pre> ... firewall { "http": protocol => "TCP", src => $facts['ipaddress'] } file { "/etc/issue.net": content => "This host is in ${server_facts['environment']} environment" } ... </pre> We could also have some custom methods in the template wrappers so accessing facts in templates could be even easiers, like `facts['ipaddress']`. Of course to help migrate users, the first release would also put the facts/server facts and parameters in the node top scope (and issue a deprecation warning on lookup). -- 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.
