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 <band...@gmail.com> 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 puppet-users+unsubscr...@googlegroups.com. 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.
