Getting module_name from Puppet 4 functions

[Alessandro Franceschi]

This is a silly question that will take to guys like Henrik less than a nanosecond to reply, I suppose, but I'm struggling hard with this and haven't found a way out.

I need to get the value of the compiler variable module_name from within a Puppet 4 function.

I've tried various approach, the one most resembling the approach in Puppet 3 function is:

mod =  closure_scope['module_name']
but it doesn't work.

Any hint?
Your nanosecond is worth at least a sunday afternoon of mine.

al

[Henrik Lindberg]

The 'closure scope' is the scope the function is defined in.
You can also get access to 'calling scope' by creating a 'system
function' instead of a regular function.

A 'system function' is special as it has more power, but it also comes
with more responsibility.

Ideally functions should not ever need anything but the arguments given
to them. It is good practice to write such pure functions. (i.e.
consider requiring that $module_name is given to the function).

A 'system function' is written like this:

Puppet::Functions.create_function(:inline_epp,
Puppet::Functions::InternalFunction) do

dispatch :inline_epp do
scope_param()
param 'String', :template
optional_param 'Hash[Pattern[/^\w+$/], Any]', :parameters
end

def inline_epp(scope, template, parameters = nil)
Puppet::Pops::Evaluator::EppEvaluator.inline_epp(scope, template,
parameters)
end
end

If you cannot spot it immediately, there are two things you need to do
in your function to make it a 'system function':
* Use create_function(:name, Puppet::Functions::InternalFunction)
instead of just create_functon(:name).
* Make the dispatcher inject the calling scope by calling
'scope_param()' in the dispatchers definition of parameters.

Then, use the calling scope to get the calling scope's variables.

The reason it is bad to directly get variables from a "calling scope" is
that it makes it hard to write general functions. What if you in a
module want to provide a function that wraps calls to a function that
picks up $module_name, or $calling_module from scope?

Thus, use 'InternalFunction' and 'scope_param()' sparingly, if at all.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Alessandro Franceschi]

Thanks Henrik,

useful and detailed info as usual.

In this case I've to manage a puppet4 version of a function, params_lookup which is widely used in all my old modules, so it's impossible to change the params passed to it without changing all those modules.

I fear I'll need to make a system function, even if not recommended.

Do you mind to give a look to it, once I complete it, in order to avoid possible bad side effects?

Thanks as usual

al

[Henrik Lindberg]

On 2015-20-07 17:59, Alessandro Franceschi wrote:
> Thanks Henrik,
> useful and detailed info as usual.
> In this case I've to manage a puppet4 version of a function,
> params_lookup which is widely used in all my old modules, so it's
> impossible to change the params passed to it without changing all those
> modules.

Note that there is nothing forcing you to use the 4.x function API (at
least not yet) ;-). Also well aware of the special functions people have
to do in order to move older code along. Hence, sharing the information
about how to achieve this (but have to include the reasons why system
functions with "special powers" should be used sparingly).

> I fear I'll need to make a system function, even if not recommended.
> Do you mind to give a look to it, once I complete it, in order to avoid
> possible bad side effects?
>

Ping me when you have something for review.
- henrik

> http://puppet-on-the-edge.blogspot..se/
> <http://puppet-on-the-edge.blogspot.se/>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-dev+...@googlegroups.com
> <mailto:puppet-dev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/2534c29c-72d7-4bbe-84c8-debe3b59f1c8%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/2534c29c-72d7-4bbe-84c8-debe3b59f1c8%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Alessandro Franceschi]

On Sunday, July 26, 2015 at 2:50:01 AM UTC+2, henrik lindberg wrote:

On 2015-20-07 17:59, Alessandro Franceschi wrote:
> Thanks Henrik,
> useful and detailed info as usual.
> In this case I've to manage a puppet4 version of a function,
> params_lookup which is widely used in all my old modules, so it's
> impossible to change the params passed to it without changing all those
> modules.

Note that there is nothing forcing you to use the 4.x function API (at
least not yet) ;-). Also well aware of the special functions people have
to do in order to move older code along. Hence, sharing the information
about how to achieve this (but have to include the reasons why system
functions with "special powers" should be used sparingly).

Actually in my case I had to do that, since the existing function was not working on P4 (it was calling an hiera function inside).

 

> I fear I'll need to make a system function, even if not recommended.
> Do you mind to give a look to it, once I complete it, in order to avoid
> possible bad side effects?
>
Ping me when you have something for review.

So, the new P4 style function is this:

https://github.com/example42/puppi/blob/master/lib/puppet/functions/params_lookup.rb

the P3 one is:

https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb

Please don't faint while looking at the code.

In the P4 conversion I preferred to keep as much as possible the same code, somehow primitive, to avoid to introduce new possible issues.

Thank you again

al