On Sun, Jul 1, 2012 at 12:58 PM, Ken Dreyer <ktdre...@ktdreyer.com> wrote: > Like you mentioned, I too would like to hear more from Puppet Labs' staff on > where they see the Module culture going.
Hi everyone, sorry for the tardy reply. I wanted to see what everyone had to say before 'weighing in'. My answer to this is a bit complicated but I'll try to be succinct. As you deduced Ken, modules on the Puppet Forge are name-spaced as author-module_name. A module installed into ones modulepath strips away author and leaves module_name. So if you were going to package them (and please feel free to!), you'd be looking at something like puppetmodule-puppetlabs-mysql for our MySQL module. Yep, it looks a bit silly but becomes less so when you look at non-PL modules. For instance, puppetmodule-rcoleman-mysql makes a lot more sense. Doing something like Debian alternatives is an interesting idea but isn't something feasible today. If Puppet Labs produces puppetlabs-mysql and I produce rcoleman-mysql, you as the consumer have zero assurance that they provide the same functionality. The Puppet Labs variant could manage the full stack while mine could just install the package. If we were in a situation where we could describe a modules functionality in factual terms to automatically make claims about whether two MySQL modules are equivalent, perhaps this could work but that's not something we can do nor do I see being possible in the platform anytime soon. On the other hand, once you get to a point where you can say the Puppet Labs MySQL module and the rcoleman MySQL module provide the same functionality, why bother having two? I'd much rather see the module community coalesce around modules that claim to do similar things, combine ideas from different groups and offer everyone one or two modules that do a thing very well. In that scenario, everyone gets the functionality they want and packaging becomes a less complicated chore. Namespace is still important so that core authors can be credited and everyone has an opportunity to put their module ideas out there. The core set of high-quality modules don't even have to be in the Puppet Labs namespace. Remember, we know Puppet, not all the various applications you use and expertly manage. Realistically, I intend to make an effort to encourage module consolidation and collaboration and perhaps we can have some sort of community ratings and review process to let the cream rise to the top, identify the tasty, creamy modules and make those the ones that get packaged by persons such as yourself. As always, we welcome your input and just want to enable those crafting modules and those consuming them to manage infrastructure and solve problems. --Ryan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
