On Apr 12, 4:01 pm, Michael Elsdörfer <[email protected]> wrote: > In general, the loading/import/namespacing mechanism is really something > that I cannot wrap my head around, even after reading the relevant sections > in the documentation. > > Specifically, I'm trying to put together a module. I believe I have the > correct module structure: > > $ find > . > ./test.pp > ./graphite > ./graphite/manifests > ./graphite/manifests/init.pp > ./graphite/files > ./graphite/files/local_settings.py
The style guide suggests a 'tests' subdirectory within the module and hints that the test manifests should be named parallel to the module manifests (or classes/defines): http://docs.puppetlabs.com/guides/style_guide.html#tests But I don't think that's the source of your trouble. > The test.pp file looks like this: > > include graphite > > This will not find the module I have placed in the same directory. If I > import the module explicitly, it still does not work: > > import 'graphite' > include graphite You're assuming that modules load relative to the manifest that uses them or something like that; they do not--only 'import' does that, as you've found, but import doesn't know anything about the special structure within the module, which is why you have to do the part below: > This does work in sofar as that the script runs a good while: > > import 'graphite/manifests/init.pp' > include graphite > > However, in that case, it isn't able to resolve puppet:// urls: > > Could not evaluate: Could not retrieve information from environment > production source(s) > > The only way I can get this to work is: > > sudo puppet apply --modulepath=. test.pp > > Is that right? Shouldn't there be a simpler way? Modules always load relative to _modulepath_ and module-loading knows where to find manifests, files and templates within the module. What you've done is pretty much what I always do, except I use the fully-qualified path to my working copy: puppet apply --modulepath=$HOME/work/puppet/modules ... This makes it easier to work from my command history (I should probably define a shell alias, I guess). There is nothing special about the top-level module directory in module path, except that your module must be a subdirectory. I was doing work recently on a module outside of my $HOME/work/puppet repo, so the module itself was in $HOME/work/foo and I was able to use $HOME/ work as the modulepath. Wil -- 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.
