Requiring for a class doesn't make sure it evaluates prior to requiring class
timurb opened this issue · comments
In many places across the whole module the construction require puppi::params is used for supposingly making sure that variables from that class are accessible in the module. Like that:
https://github.com/example42/puppi/blob/master/manifests/init.pp#L11
However this does not guarantee that at all as you need to evaluate variables from other classes prior to using them while using require foo creates an edge in dependencies and doesn't do anything with evaluation order.
To fix that expicit include puppi::params needs to be used prior to first use of any $puppi::params::* variable or class should inherit from $puppi::params to use variables from that class (I haven't played much with that latter case so I'm not quite sure in that). I'm not sure also what is the best way to fix defines.
Can you provide a real case where a dependency on puppi::params was missed o a test case with such an error?
Generally direct reference to puppi::params::* fully qualified variables is done only inside the same puppi module so that should be somehow contained.
I never actually found a problem in that, but this could be due to my own usage of the module.
Thank you for the notice.
I have not used puppi much yet so I can not point that out.
I've run into described issue while using my modules several times so I thought it is worth mentioning.
I use hiera_include in node statement (which produces generally random order of inclusion) with no plain include statements. When the class with variables gets evaluated later than the class using variables those variables finish as :undefined. Requiring the class does not imply its inclusion at the place where require is specified and actual inclusion (and evaluation) seems to me to happen at random place too.
However I use cross-module references often and have not investigated the case when using variable references inside a single module only.
I don't mind closing the ticket if I adopt to wrong approach or you don't run in errors like this for a long time. I just wanted to let you (and other people) know of the possible hard to catch problem in this setup and a cause of that.
Thank you very much for pointing out the possible problem.
I'll investigate if it may apply to this case.
Please feel free to reopen the ticket if you catch a case in the module where it emerges.