Issue #11915 has been updated by Daniel Pittman.

Ben Hughes wrote:
> This sounds like a much stronger idea.
> 
> If we're going to do something ugly with facts, like $:: because they're 
> special, why not make them special and not ugly as you propose.

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...)

> I imagine they will be "Puppet Labs" are changing the syntax yet again! But 
> hopefully this time we'll do it because it's sane, and not because "this is 
> what lexical scoping dictates one should do". We're still not Python.

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.
----------------------------------------
Feature #11915: Segregate client facts, server facts and ENC params in topscope 
hashes
https://projects.puppetlabs.com/issues/11915#change-54906

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.

Reply via email to