On 12/07/2011 06:01 PM, Christian G. Warden wrote:
On Wed, Dec 07, 2011 at 01:36:13PM -0800, jcbollinger wrote:
On Dec 6, 4:12 pm, "Christian G. Warden"<cwar...@xerus.org> wrote:
On Tue, Dec 06, 2011 at 01:38:38PM -0800, Nan Liu wrote:
On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden<cwar...@xerus.org> wrote:
Do explicit class dependencies work?
[...]
Here's the problem I was actually trying to
troubleshoot:
class config {
$x = 'abc'
}
class uses_config {
Class['config'] -> Class['uses_config']
$x = $config::x
}
include uses_config
include config
This results in:
warning: Scope(Class[Uses_config]): Could not look up qualified variable
'config::x'; class config has not been evaluated
I think it's similar to the problem I asked about with tags in another thread.
If I include config before uses_config, I don't get an error.
Indeed, it is at least partially a parse order issue, and it looks
like you may be confusing that with application order.
Thanks, John. This explanation is very helpful. Indeed, I've been
having trouble understanding what happens during the parsing/compiling
stage.
See https://projects.puppetlabs.com/issues/10972.
What's even cooler is if you try (at least on my 2.6.2 installation) to
evaluate that with puppet agent rather than puppet apply, you get no
error at all. $config::x will evaluate to undef, which will happily
interpolate into a string as "". So if you have this:
file { "$config::x/somefile.conf": ... }
now all your files are created in /. Hooray!
You are not alone in being frustrated in this behavior. The
documentation is self-conflicting and the language semantics aren't
actually what they say they are. When the docs say the language is
"declarative" (which doesn't really have much meaning), they usually
also say something about order not mattering. Order not mattering is a
property of purely functional languages, and many clearly declarative
languages are purely (or mostly so) functional. The problem is that
puppet can't actually be purely functional, because it isn't a single
assignment language. Sure, the obvious case of reassigning to the same
variable in the same scope isn't allowed, but what about the non-obvious
cases, like:
- class inheritance
- collection overrides (Foo <| |> { ... })
- parameterized classes vs. "include"
As it turns out, these are the places where single assignment really
helps one reading the code reason about it. It's quite easy to see the
order of assignments and interactions between multiple lines in the same
file. It's much more difficult to absorb the ordering and interactions
between components that live in different files, or even different
modules. Yet, it's these far-reaching reassignments that are allowed,
while the short-range, easily understood ones (simple $foo=bar) are the
ones that are forbidden. Go figure.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
