+1 to everything that John has said. While many Forge modules are not useful to me out of the box, I have had good luck modifying them to meet my needs at any given time.
I've also been able to learn new ways of doing things (and not doing things) due to the willingness of people to share. I do think that some of the recent proposals around allowing multiple modules that cover the same material to exist on the same system are a good thing and could help with reusability in the future. In this case, you would get chunks of reusability that work together but that happily coexist with other isolated chunks. It's good to have these types of discussions though. Knowing different users' ideas of perfection can encourage different automated methods of attempting to attain perfection in the future (puppet-lint for example). Thanks, Trevor On Fri, Jun 20, 2014 at 11:04 AM, jcbollinger <john.bollin...@stjude.org> wrote: > > > 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 > <https://groups.google.com/d/msgid/puppet-users/e30a76b9-3f1a-4408-8cc4-d4c2a2207874%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoW4Op7RTM6uxqrgJLRh1yunLOcMorW%3DU4O61FNnm4-8YQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
