Also... my earlier assumption seems to be correct. In principle, at least. Just looking at the "best practices layout" autogenerated there... this seems to be primarily geared towards *classes*, and end user "modules". Not back end "here's a whole new resource type" code.
A module is more than just classes. These classes might need the resource types that this module bring with. And therefore I don't see a reason why plugins (you call it back-end code) shouldn't come with modules as well.
Afair the whole idea of what a module is is pretty well described in the documentation.
And IMO, that's as it should be. Back end ruby language code should be held separate from regular "puppet language code" stuff.
It is - in the plugin aka. lib/ directory of a module.
But that doesn't leave me a clear path for how to have my svcprop resource shared out to others. As a suggestion.. if you guys INSIST on overloading the term "module", to cover both user-level code, and back-end code, then I would recommend you add an additional, separate subcommand to puppet-module, that generates back-end templating, instead of the default user-side templating.
It is not that easy to say, that all puppet code is user-level code. There might different levels of abstraction and you might end up with puppet code that has the same functionality as what you are calling back-end code.
~pete -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
