Puppet

Could we see your code, so we can better assess what is going on? Also, any other information you could send us would be great.

That is probably caused by the $sites and $mods variables which are used in the example to shorten/configure the paths of the apache config. Probably something went wrong when migrating those to the module.

Take a look at my git repository at http://git.black.co.at/?p=manifests.git;a=shortlog;h=apache for an updated and modularised version of the apache class. You can get it as described in http://git.black.co.at/?p=manifests.git;a=blob;f=aux/README.split-modules;hb=HEAD

Michael: see above; only real modification is to protect hostnames and IPs.

Just tried renaming the apache2_mods and apache2_sites variables but no change.

Going to a much simpler example, the following code does not work:

# test.pp
include mymod

# ~/tmp/modules/mymod/manifests/init.pp
$test_variable = funtest

class mymod {
    notify { "testing $test_variable yay": }
}

# Running it:
luke@phage(0) $ test.pp --modulepath ~/tmp/modules/
notice: testing  yay
luke@phage(0) $

If I just include the class directly and run that file separately, it works fine.

The problem is that we’re evaluating ‘main’ before we evaluate anything else, and generally we’ve evaluated main before we get to the point where we’ve imported the module.

I’m not sure there really is a good solution to this. It might make sense to auto-evaluate any code that would otherwise get added to main if main is already evaluated, but… Man, that’s scary.

In the meantime, there’s a trivial workaround: Just manually import the module. This will add the variable-setting code to main at parse-time, rather than at evaluation time:

# test.pp
import 'mymod'

include mymod

# Running it:
luke@phage(0) $ test.pp --modulepath ~/tmp/modules/
notice: testing funtest yay
luke@phage(0) $

There’s a very good chance I may just call this workaround sufficient and not fix this bug.