On Thu, Sep 5, 2013 at 5:06 PM, Jeff McCune <j...@puppetlabs.com> wrote:
> On Thu, Sep 5, 2013 at 2:44 PM, Luke Kanies <l...@puppetlabs.com> wrote:
>
>>
>> "'include' should defer evaluation of classes with parameters in case a
>> more specific evaluation is available"
>>
>> Right?
>>
>
> Yes, though I've been expressing it a bit differently. It shouldn't
> matter what order I say `include foo` or `class { foo: bar => baz }` in
> because Puppet is declarative.
>
I know that "Puppet is declarative" gets used a lot, but really it isn't.
There are two parts to puppet that could be called declarative: the puppet
language and the puppet catalog.
The puppet language is an SSA, imperative language. If you didn't have
custom functions it could be classified as functional (that is a very odd
thing to assert, but many custom functions are for side effects). If you
take away everything but resources, defines, and dependencies, then it
could be called declarative, however, that subset is probably not what most
people consider the puppet language.
The puppet catalog is a declarative program (roughly) for enforcing a
configuration state. Since the catalog is equivalent to the puppet language
stripped down to resources and dependencies, that is why that subset of the
language could be considered declarative.
Do you think it's a mistake for 'require' to call 'include'?
>>>
>>
>> Yes, it's a mistake for require to call include.
>>
>> I couldn't agree less. As Patrick mentioned, if people actually use
>> contain, you'll see a lot of 'include(foo); contain(foo)'.
>>
>
> Sure, and why is this a problem? As the module author I'm clearly
> communicating to the parser and to other readers that my intent is to
> include the class and to contain the class.
>
> With a contains() that has side effects the ability to express "contain
> but let someone else include" is lost and the side effect of "include the
> class" is unclear to the reader.
>
> Wouldn't it be better to just fail right at the location of contain() if
> the class isn't in the catalog? This would avoid the error message on line
> 20 which is caused by the side effect on line 12 in my example. The error
> would be right at line 12 and would be more clear to the reader.
>
> If I were using it, I'd literally write something like a
>> 'contain_and_include' function, because this would annoy me a lot.
>>
>
> Sweet, that function 'contain_and_include' is very clear about the intent
> you're trying to express. If I were to hazard a guess at your intent, you
> want to both contain and include a class.
>
> It also accommodates anyone who wishes to contain a class without also
> including it.
>
> As long as the above bug were fixed (assuming others agree it's a bug),
>> there shouldn't be a problem at all.
>>
>
> Sure, but we're not talking about fixing incompatible class declarations.
> We're talking about fixing #8040.
>
>
>> include should be idempotent; you've just found an area where it's
>> apparently not.
>>
>
> Include is idempotent and always has been. It's resource style class
> declarations that aren't idempotent, cause the issue and are incompatible
> with include.
>
> We're not talking about fixing those issues though, we're talking about
> fixing class containment.
>
> Is the proposal that we block fixing #8040 on reconciling resource style
> class declarations with include()? If so is it in an effort to avoid
> having to clearly express include(); contain() when you mean "include and
> contain" versus just contain() when you only mean to express containment
> and defer inclusion to something else?
>
> As Patrick points out, it's difficult to add edges to the catalog when a
> class has not yet been evaluated. What I'm thinking is that it's still
> better to fail with a clear error message in this case just as my original
> example did with "class cannot be declared twice." contain() should fail
> today with "class is not in the catalog" until we're able to defer the
> behavior of containment until the class has been evaluated.
>
> -Jeff
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
