A small note on params.pp, even if I've largely used it in the Example42 modules there are cases where it's totally uneffective, for example when you've to define there a parameters whose value may change according to another parameter the user may pass to init.pp
An example is here: https://github.com/example42/puppet-logstash/blob/master/manifests/init.pp#L439 or even worse here: https://github.com/example42/puppet-elasticsearch/blob/master/manifests/init.pp#L399 where some parameters change according to the installation method and I found myself placing horrible static references in init.pp I still haven't found an elegant way to manage cases like this but, working with different modules scenarios I'm more and more convinced that different design patterns should be used according to the kind of module you're doing and the kind of options you want to throw in (for the above examples all the extra complexity is due to the option to have the possibility to choose how to install the application (via a package, downloading the upstream tarball ...). my2c al On Wednesday, August 14, 2013 1:08:28 AM UTC+2, Ellison Marks wrote: > > Ah, good to know. I'll file some tickets as I come across instances of > this. > > On Tuesday, August 13, 2013 2:47:43 PM UTC-7, Ashley Penney wrote: >> >> As one of the two new maintainers of all Puppetlabs modules I can tell >> you for sure that our intent is to make sure everything in init.pp inherits >> out of params.pp instead of declaring them directly in the main class, and >> if you're kind enough and can throw a github issue up for any cases you >> notice where that's not true we can fix them. >> >> I never liked the params.pp pattern myself but there's no great solution >> to "where do I store all my weird logic to make the rest of my classes >> simple". We're standardizing on keeping all params defined in params.pp >> and inheriting that in init.pp so that they can be overridden. >> >> I can't claim it's the best pattern, but we're at least going to strive >> for consistency. >> >> (For background, each puppetlabs module was written by a different person >> with their own views on this stuff and we had no unifying style guide or >> guidelines to work from. We're working on fixing these, but it takes time >> and we don't want to barge in rewriting everything and upsetting current >> users). >> >> >> On Tue, Aug 13, 2013 at 5:32 PM, Ellison Marks <gty...@gmail.com> wrote: >> >>> So, I've been looking into the params pattern for writing modules, ie. >>> having a params.pp file that init.pp inherits from as a place to use custom >>> logic to set variables, and it seems very useful. I do have one question >>> that I'm hoping someone can answer. If, for example, I look at an example42 >>> module, everything is in params.pp. On the other hand, looking at, say, >>> puppetlabs modules, there's some mixing, with the case statements >>> determining variable contents living in params.pp, but with straightforward >>> string and boolean values stored between params.pp and the argument list in >>> init.pp, with seemingly little logic dictating what goes where. >>> >>> Basically, what's people thoughts on the value of having every single >>> variable defined in params.pp, vs only the complex, logicky ones, and also, >>> in the case that I'm being dense, can someone explain the logic behind the >>> puppetlabs modules. >>> >>> -- >>> 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...@googlegroups.com. >>> To post to this group, send email to puppet...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/puppet-users. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- 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. For more options, visit https://groups.google.com/groups/opt_out.
