I personally went the tiny class route, creating a module with a bunch of little classes for various packages. I opted for this route as it let me deal with naming differences between apt and yum, and let me do repo dependencies for stuff in Epel.
Here is an example: https://github.com/TJNII/puppet-commonpackages/blob/master/manifests/python/argparse.pp I'm currently not making use of the forge, at this time I'm still rolling my own modules. So that's a bridge I'll likely have to cross later. -- On Tue, 19 Nov 2013 11:48:26 -0800 (PST) Matt Simmons <[email protected]> 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? > > Thanks, and sorry for what I'm sure is an overly-basic question, > > --Matt Simmons > > > > > -- 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/20131127110935.660409a7%40TJNII-Desktop.rackspace.corp. For more options, visit https://groups.google.com/groups/opt_out.
