First of all, let me thank you, John, for replying to this post and giving a sense to the discussion. At times I wonder if PuppetLabs' guys read the forum and, if they do, why they don't express an opinion on these matters. I might be obsessive about modules, but I think that it's here where we play the most important game on user code reusability.
On Friday, June 20, 2014 5:04:28 PM UTC+2, jcbollinger 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. > Reusability is definitively a relative concept, and I agree it can have different nuances, still, IMHO, there are a few reusability patterns that are easy to introduce and add a great value (for example the possibility, for the module's user to provide custom templates for configuration files instead of the ones proposed by default by the module. This is easy to introduce and should definitively be common practice). > > 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 understand the point, but at the same time I find it harmful also to have hundreds of modules, that are published on the forge but work only for a specific case and are practically useless for others. It's not a matter of preventing or discouraging users from publishing their work, but to have a good overall quality of public modules and to encourage good practices. I'd rather work on trying to convey and promote basic reusability patterns that can be used and embraced by everybody. Also, I don't think that a reusable module is necessarily a good one or viceversa, actually in most the cases reusability features add complexity and overheads. > 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. > All good points that diverge a bit from the discussed topics and are not alternative. I suppose priorities are rather subjective, after all. Incidentally, I've published the second part of the blog post this thread is about: http://www.example42.com/2014/06/22/rethinking-modules-part-2/ it describes better that Tiny Puppet idea I introduced in another thread we talked about: https://groups.google.com/forum/#!topic/puppet-dev/4lFhfChM9XM (and yes, at the end I mimicked Hiera in the module with a custom function) Al -- 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/75a29228-ea89-4e06-bf43-9d4c84bbbdca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
