>> > I looked at the "forge" thing, and the "puppet-module" tool. >> > Sad to say, I did not like it, for this purpose. It seems too complex >> > compared to the alternatives. >> >> Do you really think its hard? I was under the impression it was >> relatively easy these days. > > > huh. I dunno, lets just say that it did not seem that way at > https://github.com/puppetlabs/puppet-module-tool/blob/master/README.markdown > > If I have to go trawl through over 1,000(?) words, and scroll down multiple > pages, to find out how to do something that is supposed to be "easy"... (and > still havent even gotten to the details), I start looking elsewhere. > I suspect I'm not alone in this :)
So the principle is: * Create a Modulefile according to the defined format in that doc * Run 'puppet module generate' (or puppet-module generate if your using the old tool) * Create a forge account * Create a project * Create a release * Upload the previously created tarball from pkg/ into your release. (Take note that the PMT module is available built-in to Puppet with modern releases of Puppet - so you won't need that separate tool any more.) Once this happens you should be able to do: * puppet module search <module_name> * puppet module install <module_name> If all is working well ... >>> So okay - the way I read this was that the tool is to be unpacked >>> >>> inside the Puppet core source files? Am I mistaken here? Ordinarily >>> >>> 'modules' are kept away from the core files - as plugins shouldn't be >>> >>> mixed with core. >>> >>> > > > Huh. well since the details of this werent mentioned in > http://docs.puppetlabs.com/guides/complete_resource_example.html > it kinda fell of my radar. Would be nice if it had a very brief, focused > mention of this here. > > Comment on that though: > It seems like, > from http://docs.puppetlabs.com/guides/plugins_in_modules.html > that it would be expected to install under > /var/lib/puppet/lib/modulename/lib/puppet/ > > Could we be less redundantly redundant, please? :-} > Yikes.... :( > > Chopping off the trailing "lib/puppet" stuff, seems to be more reasonable. > Seems like the primary reason yoy do that is for facter extensions. But > facter stuff, belongs with facter, not under a "puppet" dir. > It has its own directory under ruby site_ruby, after all. And it's own > "Separate" installation tarfile, etc, etc. Actually this isn't correct ... on the puppet master modules should live in the modulepath directory, which for the OSS version is usually: /etc/puppet/modules/<module_name> Then when clients run they get 'plugin-sync'd to the 'libdir' which is: /var/lib/puppet/lib/<puppet|facter>/... Uploading your module to the forge means the download and placement of code into the module path should (with a good setup) go into the right place, so a lot of this pain isn't felt by the user. > Not to mention that, while I consider classes, etc. to be part of the > "manifest" stuff... I consider stuff that is actually *ruby code*, rather > than puppet code, to belong with the ruby code. > Mixing the two feels extremely wrong to me, from my CompSci background. > /var/blah and /etc/blah are for the manifests & classes: $RUBYDIR/site_ruby > is for ruby code, imo. > How about a ruby_gems way to distribute that stuff instead, that collects it > under the ruby/puppet tree somewhere? Lets get your module working the preferred way first and then you can evaluate its pluses/minuses under that context :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
