On Thursday, June 19, 2014 11:09:22 AM UTC-5, Alessandro Franceschi wrote: > > Hi all, > I've written a blog post with my opinions on the current modules ecosystem: > http://www.example42.com/2014/05/31/rethinking-modules-part-1/ > > The post talks about : > What are the reusability features a module should have, imho > The distinction between application (component) modules and higher > abstraction modules > What are the challenges and reusability options for higher abstraction > modules > > It also raises a pair of points of the challenges that, according to me, > we should face in our future modules: > Patterns to extend reusability of higher abstraction layer modules > Standardisation in the component application modules > > I'm truly interested in hearing others' opinions on these topics, in order > to understand if such points are important only for me or they reflect > common concerns. > >
I have never accepted the premise that "reusable" as applied to Puppet modules has to mean "usable in any context, to achieve any end related to the module's area of application, via any conceivable style," which is pretty much how I read your reusability criteria for component modules. Certainly a module that satisfies those criteria can serve pretty much any purpose within its domain, but what matters to me at any given time is whether a module can serve *my* purpose, whatever that happens to be. If some third-party modules are (re)usable for me but not for (say) Felix, and vise versa, then that doesn't change the fact that both our jobs are made easier by not having to write everything from scratch. If that means I need to study a module a bit before I decide whether to use it, then fine -- I ought to do that anyway. Moreover, I think it is harmful to the module ecosystem to promote a position that only Cadillac modules are "reusable," because that sets the bar very high for potential contributors. I don't think it helps anyone to tell people that their contributions are unwelcome (which branding them "not reusable" does). Most people who write modules do so for their own purposes first and foremost, and if the community is unwelcoming to them then they will just keep their work to themselves. I agree, however, that there is a useful distinction between "component modules" and higher-level modules, and also that some higher-level modules are conceivably reusable. I furthermore agree that the criteria you set out all tend to make such a higher-level module either applicable to more use cases or easier to integrate. On the other hand, I tend to think that higher-level modules will less frequently be used together on the same nodes than are component modules, so that integration considerations are less of an issue. I also tend to think that reusable higher-level modules will be fewer than component modules, so that standardization is less of a consideration for them. Of course, I think I ascribe less importance overall to standardization (of Puppet modules) than you do. I have recently decided, too, that more of the responsibility for module reusability has been placed on module authors than is needful or useful. Puppet itself could and should provide more support than it does. In particular, I would like to see more flexible data binding (e.g. a mechanism for data aliases and/or indirect data names, a mechanism for slicing data, improved DSL-based data injection, etc.), and more flexible class / module resolution (e.g. aliases / indirection). These sorts of features would improve *all* modules' reusability by opening more flexible approaches to integrating modules into a site's manifest set. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e30a76b9-3f1a-4408-8cc4-d4c2a2207874%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
