On Tuesday, November 19, 2013 1:48:26 PM UTC-6, Matt Simmons wrote: > > Hi John, > > I'm new around here, but I'm also in the same situation as Tom, who > started this thread. > > I was wondering if you could expound a little bit on the better solution > that you mention. I write what I could refer to as "third grade puppet", > but I'd like to get better. > > When you suggest factoring out these resources into separate classes and > modules, do you mean that, in essence, all possibly-shared resources should > be in discrete modules or classes? How does that jive with modules included > from Puppet Forge? Doesn't that mean refactoring everything you include > there, as well? >
I do not mean that possibly-shared resources must necessarily go into their own tiny classes, though that would be one way to go about it. I mean that any given resource must belong to exactly one module, in such a way that using the module via its public-facing classes and types cannot by itself cause multiple declaration. The module owning any particular resource might reasonably be one obtained from the Forge, or it might be a home-grown one. That multiple modules might attempt to own the same resource is a thorny and longstanding module compatibility issue -- two modules that both attempt to own the same resource are not compatible. Such a pair can be rendered compatible either by making one module depend on the other for the resource, or by making both depend on some third module for it. Needless to say, that involves modifying one or both of the modules. John -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/15b590a6-0fb1-4ffe-8ce0-222fc4beb49c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
