To answer everyone all at once, I am hoping to make this a tool for generating manifests and I'll take both approaches to see what works best.
I'll also keep this on -users since it's a spare time project as opposed to something that anyone should pay a great deal of attention to at this point. As always, I appreciate the quick and helpful responses from the list. Good luck with the sleep, it should catch up in another year and a half or so :-/. Trevor On Tue, Mar 10, 2009 at 04:25, Luke Kanies <[email protected]> wrote: > > On Mar 9, 2009, at 9:56 PM, Trevor Vaughan wrote: > >> This is sort of on topic for users, but I'm more than happy to move it >> to 'dev' if appropriate. >> >> What I'm trying to do is to create a basic GUI that allows me to >> detect: >> >> 1) What modules are installed on the system >> 2) What classes are in the modules >> 3) What defines are in the classes >> 4) What defaults/requires are in place in the defines >> 5) Anything in a general manifest that is outside of a module >> (secondary) >> >> I started down a path of trying to detect all of this myself and then >> realized that I'm being a bit stupid since that entire logic structure >> is present in the Puppet compiler. >> >> Unfortunately, I've been wading through the code with very little luck >> at figuring out how to hook/call/override (whatever) this logical >> segment of the Puppet code. >> >> Am I going down the right track and, if so, how would I tap into the >> Puppet compiler in this way? >> >> Alternatively, would it just be easier to collapse the modules/ >> manifests >> and parse them from there? >> >> Thanks for the indulgence, I intend to release this thing if I ever >> get >> it to a state that is actually useful. >> >> I'm writing it in using a GTK+/Ruby combo since QT makes my hair stand >> on end. I'm also writing it in my spare time, so who knows how long >> it >> will take. >> >> Thanks for any help that is offered. > > As James Bellenger says, it may be that what you're looking for is > already in puppetdoc, but in case it's not... > > You should be able to create a parser instance, trawl the filesystem > and call 'parser.import(file)' for each .pp file you find. This will, > at least, give you all of the classes, nodes, and definitions you > have, via simple accessor methods on the parser ('nodes' for nodes, > etc.). They're all stored as hashes on the parser. > > Modules are both more and less complicated. I think both branches are > a bit messy on this, but frankly, just iterate across the module path > and look for directories, and you're basically done. This is easiest, > but not necessarily most useful. I just made some changes to master > that makes htis cleaner, but it probably doesn't help much. > > And I'm not sure on whether this goes to -dev or -users, so eh. My > only caveat is that I check -dev religiously (it still goes to my > inbox) but -users only when I have time (like when it's 3am and I > can't sleep :/). > > -- > Men never do evil so completely and cheerfully as when they do it from a > religious conviction. --Blaise Pascal > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
