On Tue, Sep 3, 2013 at 11:34 AM, Drew Blessing <[email protected]>wrote:
> I've been following this discussion for some time. As it progressive I've
> found myself fighting internally, going one way and then the other about
> how this should really be. I keep coming back to the same place - this is
> a bug and Luke's original statement is very important:
>
> The fix should require no changes to syntax or usage; merely the cessation
>> of use of the anchor pattern.
>>
>>
> I don't think adding a new 'contain' function is really appropriate. From
> a module developer standpoint what does 'contain' mean? Why should I use
> it? When should I use it? I think it will cause so many questions that
> you'll end up with a whole different problem on your hands. On top of that
> you will have people that just continue to use 'include' and the problem
> will still be there.
>
>
This is the tradeoff between changing existing language constructs to match
some user's expectations, and thereby breaking some manifests, or adding
something new to express the specific concept of containment, and thereby
requiring users to make a conscious choice about what they want. I agree
that pawning this off on a user is not ideal, which is why I've argued for
changing the semantics of the resource like syntax for classes. However, as
jcbollinger has rightly pointed out, that change would break a lot of
things, and would also be a major shift in the way many users understand
the language.
This is the reality we find ourselves in. Over the course of the
discussion, I think jcbollinger's proposal is probably the best for
existing users. Those who are currently using anchors would be able to
change to the new contain() function. Existing manifests would not need to
change, but they could be updated to use the new function. Luke also
brought up another alternative for creating a new container kind (module {}
or something like that). I think that would be another good avenue to
explore.
> In my mind, if I use 'include' or class resource syntax it means 'make
> sure this is in the catalog *at* or *before* this class'. I don't care
> what contained means. As such, I expect that when I include/declare a class
> that the class *and all* of it's included resources/classes/etc get put
> in the catalog *at* or *before* my class. On the face it's that's simple,
> it makes sense, and people will understand it. I think the fix for the
> anchor pattern needs to require no more than this from a module developer
> standpoint.
>
>
If that is all that you want, then you can get that today by using
require() instead of include().
> --
> 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.
>
--
Andrew Parker
[email protected]
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 [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.
