Is this level of namespacing enough? What happens when a module (mymodule) depends on the "mysql" module but you chose a mysql module that isn't quite the same as the one mymodule expects?
Thanks Mark On Monday, July 2, 2012 11:33:42 PM UTC-4, Ryan Coleman wrote: > > On Sun, Jul 1, 2012 at 12:58 PM, Ken Dreyer > <ktdr...@ktdreyer.com<javascript:>> > 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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/VN72ADYnUP0J. 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.
