On Thu, Sep 5, 2013 at 2:44 PM, Luke Kanies <[email protected]> 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.
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
