On Jan 29, 2013, at 8:51 AM, jcbollinger <john.bollin...@stjude.org> wrote:
>> The only way to force parse-time ordering right now is to do a direct >> include, unfortunately. >> > > > Yes, but I'm not sure I would say "unfortunately" there. The problem is not > so much with any limitation of Puppet DSL in this area, but rather an issue > of module design and manifest set architecture. > > I mean, one should be very careful and deliberate about designing modules > such that their classes need to rely on class variables of other modules' > classes. Indeed, it is probably a poor idea to implement such a design > unilaterally -- instead, the module providing the class variables should be > designed and implemented in anticipation of that usage as well. That > probably means 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. > I'm not sure I fully agree with this from a design standpoint. In object-oriented programming, one of the design principles is that variables relating to the object are encapsulated within the object and exposed or not depending on how they should be accessed. IMHO, it also makes it more obfuscated when you're accessing say the SSL CA cert path variable and that's in some 'common' module that everything has to include. Granted it makes it easier on the module developer - just always in include the common module and your variables should be there - but it also makes it less explicit. I would argue, if you're writing a module that depends on using the SSL CA cert path you have some dependency on the SSL module and should have some understanding of what that module does and the ramifications of using that module, so you should explicitly include that module for that dependency. In just about every language you must include the external modules/libraries you depend on for functionality outside the standard norm. In puppet the standard norm - the stdlib.h equivalent if you will - I would consider to be facter variables. You want to use LDAP or SSL or Kerberos? You best include those modules explicitly and figure out what you can use from them - ldap.h <> ldap::params, ssl.h <> ssl::params, etc. Standardize how you create these public puppet 'headers' and use them explicitly and appropriately that way. At least that's my 2c. -- 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.
