Developing a module: Use it from the current directory?

482 views
Skip to first unread message

Michael Elsdörfer

unread,
Apr 12, 2012, 7:01:09 PM4/12/12
to puppet...@googlegroups.com
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 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

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?

Wil Cooley

unread,
Apr 15, 2012, 11:19:13 PM4/15/12
to Puppet Users
On Apr 12, 4:01 pm, Michael Elsdörfer <elsdoer...@gmail.com> 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
Reply all
Reply to author
Forward
0 new messages