The difference between 'a' and 'b::b' was that 'a' didn't have a file
declaration, it had a resource declaration that had a file declaration. So
if I created a new resource that wrapped 'b::b' then I got a straight
forward parse-order dependency.
I tend to use defined because it allows you to under gird something without
that something actually knowing who you are. In this case the plugin was
git. I was using the repo resource to checkout some code. It was
declaring the folder that was going to be checked out. Defined works nice
because when you read it, you understand what they are trying to do, even
if puppet has a hard time producing that result. Alternatives I have read
involve defining a class and including it. But that requires git to know
about said class, also it doesn't work for resources which applies in this
case. The other alternative I have read about is something like
virtualized resources? You manifest them at each point. I have not really
seen any good documentation on what it is, how it works, what it requires.
The code I have seen does not make it clear to the user what is taking
pace, it just doesn't read well.
If you declare things something like this psuedo code:
A
C
F1
B
D
F2
When people read it they are going to more commonly expect the order to go
A
C
F1
B
D
F2
Not
A
B
C
D
F1
F2
In git they set recurse to true. Compound that with a resource default up
the declaration stack and you have puppet spending a long time uselessly
changing the ownership and permission on a ton a files when they get
checked out. I find the dynamic scope of resource defaults to be more of a
surprise and a burden then a useful tool.
Anyway I am resolved, thanks for the help.
On Tuesday, April 23, 2013 4:09:02 PM UTC-7, Nick Fagerlund wrote:
>
> If the relevant code were just sitting there naked in your site manifest,
> I think you'd probably see a fairly simple parse-order dependency -- I
> think it's the fact that they're in defined types that's shifting things
> around. Actually, one of the core team surprised me the other week by
> telling me that defined types are somehow late-binding when creating their
> resources, in a way that classes aren't; I can't remember why they thought
> it had been implemented that way, though.
>
> The point is, this is EXACTLY why we say to not use `defined()` like that,
> is because it can cause havoc for downstream users like you. I'm afraid
> you're going to have to fork b::b and go in and muck with its
> implementation if you want any certainty around this behavior.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
