On Mon, 2008-11-03 at 23:14 -0600, Luke Kanies wrote: > On Nov 3, 2008, at 1:55 PM, Brice Figureau wrote: > > > I'm currently working on it, unfortunately I'm stumbling across an > > issue.: > > > > I want the rdoc generator to be independent of any configuration (ie > > modulepath), so that we can point it at any directory and let it scan. > > > > That means that I have to find an heuristic that says, this manifest > > file is part of a module or this manifest is part of the global > > 'site' part. > > > > My first thought was to check that there is a 'files' and a > > 'templates' > > directory in the same path as the manifests dir. For an unknown reason > > some of my own modules only have the manifests directory, so it seems > > Puppet doesn't enforce the presence of this dirs. > > Hence, I can't use this heuristic as is. > > > > I can check for a 'modules' directory and infer from that I'm > > scanning a > > module, but that seems quite artificial and error-prone. > > > > Any idea of a better heuristic, or should I bite the bullet and use > > the > > current puppet.conf to check for modulepath? > > > That's probably the best choice for now, unfortunately. > > You could do the "right" (and thus, as always, harder) thing, which is > to automatically associate the classes with the modules they were > generated from, but I think this is relatively hard, design-wise. It > would likely involve a complete refactor of Module, which is long past > due but non-trivial. > > All manifests are searched for using Puppet::Module.find_manifests, > and right now it's a pretty simplistic method, but it could be > modified to return information about where the manifests were found. > > Then you mark the parser in some way when you're parsing, so that as > classes are created you know which module they're from.
Yes I do agree it would be the best solution, but... > I unfortunately haven't thought about this enough to have a real > design, though, so I think for now, you'll have to stick with checking > for whether the file begins with a path in the module path. Note > that :modulepath is a colon-separated list, not just a single value. My concern is that puppetdoc right now doesn't use puppet.conf at all, and I'd like to keep this behavior. I want to be able to generate docs for a pile of manifests, modules or not. If I tie puppetdoc rdoc generation to puppet.conf :modulepath, then the only rdoc puppetdoc will be able to generate will be the manifests hosted on the current puppetmaster for a given environment. We could go this way (that'd be way simpler to know where the manifests are, or where the modules are), but then it fixes the documentation puppetdoc can generate (ie it'd be impossible to put some modules in a path and run puppetdoc over it). Or I could change puppetdoc rdoc to take more arguments like "--modulepath /path/to/modules" along with the path where to find the "global" (or site) manifests. If --modulepath is not mentionned then we assume that analysed path contains only modules. Does it make sense? -- Brice Figureau <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
