On Friday, June 20, 2014 8:01:49 PM UTC+2, Trevor Vaughan wrote: > > +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. >
Well, in my very personal opinion, if someone takes a module of mine and has to modify it in order to make it meet his needs, I've lost. I think, as a general rule, that every Puppet setup should have at least 2 separated directories in the modulepath. A shared, common, one, with public modules downloaded from the Forge or other sources, and not modified. A site, local, one, with local modules and eventually the public modules that have been downloaded and changed (the less of these, the better) for local needs. > 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. > Are you referring to these? https://groups.google.com/forum/#!topic/puppet-dev/em-WGLCrdIw https://groups.google.com/forum/#!topic/puppet-dev/dkdXaUt8yDg > 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). > Indeed, and actually this was the reasoning behind this post, as sometimes I wonder how some things I consider obvious or necessary really matter and are considered useful by others. I generally try to figure out solutions following the current status of the Puppet language (I consider myself an end user) also considering the inevitable lapse of time that occurs from a feature development to its usage at large. Still, proposals as the ones expressed in the linked threads are definitively worth attention, thanks Al > > On Fri, Jun 20, 2014 at 11:04 AM, jcbollinger <[email protected] > <javascript:>> 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 [email protected] <javascript:>. >> 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 > [email protected] <javascript:> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1c9e8439-08bb-4906-97ad-654e5923a916%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
