On Wednesday, January 30, 2013 3:41:31 PM UTC-6, Ti Leggett wrote: > > > On Jan 30, 2013, at 2:33 PM, jcbollinger wrote: > > > Maybe we're just having a terminology problem. Puppet has no concept of > sub-modules, and the only construct available to hold reference-able, > non-global variables is the class. Indeed, even modules themselves are a > Puppet implementation detail -- the DSL has no concept of them except as > top-level namespaces (but top-level namespaces often map to classes, either > instead of or in addition to mapping to modules). > > > > So, would you care to explain how your <module>::params then differs > from "mash[ing] all the public bits in to one globally public class that > has no nitty gritty bits to implement"? Are you suggesting separate > ::params classes shadowing multiple different classes in the same module? > Are you conflating class parameters with class variables? > > > > Let's go back to my original example from http://pastie.org/5910079#. Not > stated in that code snip (for conciseness) is a module, kibana. Among other > things it needs to install an apache configuration to make it a useful > piece of software and that configuration is in the kibana::apache sub-class > in the form of a snippet that is tagged such that the apache module can > instantiate it later on at the proper time (there's an alternative to this > method). In order to do this, the kibana::apache class needs to know where > to install this configuration file so that the apache process can load it. > That location I chose to place in a variable, $config_d, in the apache > module in a sub-class (sorry for the improper nomenclature before) > apache::params. To solve my original problem I simply add: > > include 'apache::params' > > right above the @file snippet in kibana::apache and everything is happy. I > think everyone can agree that is the right solution to the problem that I > posed; however, both you and Luke strongly suggested against having modules > include other module's variables willy nilly and instead move those > variables that multiple modules need to reference into a globally included > class, we'll call it globals::.
No, neither Luke nor I recommended any such thing. I don't even see how you could tag Luke with that, though I do now see how you could have misunderstood my own remarks that way. My original comment about "centralizing all variables intended for cross-module reference in one well-known class, documenting their names and value ranges, and committing to avoiding incompatible changes there" was made and intended to be interpreted in the context of designing an individual module, so that the "one well-known class" is *for that module*. My apologies for being unclear. A per-module ::params class, as you seem to be advocating, is completely consistent with my recommendation. Even with that alternative, however, it is best to minimize cross-module class references (as Luke previously said), and I particularly like the example he just offered for a means of doing so. I'm inclined to think that it would be less prone to tricky parse-order issues and dependency cycles (or insufficient dependencies) than what you describe doing in your kibana module. 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 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.
