After some debugging, I finally found this post.
Thank you for posting this issue, that saved me probably a lot of time :-)
I had this problem with jfryman's nginx module, when I tried to create some
vhosts with or without the parameter "auth_basic".
Atm I've some auth_basic => undef resulting in a broken nginx vhost file,
because the nginx module getting an empty string and putting it into the
vhost config.
Instead of an undef and doing nothing :-)
Anyway: "fixed" it with a condition like the following and looking forward
to 4.x ;)
if $auth_basic == undef { create_resources $vhost_hash } else {
create_resources $vhost_hash_without_auth_basic }
Am Montag, 2. Juni 2014 15:52:13 UTC+2 schrieb Henrik Lindberg:
>
> On 2014-31-05 2:15, Robert wrote:
> > I've stumbled upon this very annoying bug with the future parser where
> > it's replacing undef with empty strings when passed inside a hash to
> > create_resources().
> >
> > test.pp
> > =========
> > define test($var = undef) {
> > notice inline_template("<%= @name %> is <% if @var %>true<% else
> > %>false<% end %> and of type <%= @var.class %>")
> > }
> >
> > $config = {
> > "from_create_resources" => {
> > var => undef
> > }
> > }
> >
> > create_resources('test', $config)
> > =========
> >
> > $ puppet apply ./test.pp
> > Notice: Scope(Test[from_create_resources]): from_create_resources is
> > false and of type NilClass
> >
> > $ puppet apply --parser future ./test.pp
> > Notice: Scope(Test[from_create_resources]): from_create_resources is
> > true and of type String
> >
> > Breaks most of my templates since I use <% if @var %> everywhere...
> >
>
> That is a bummer. The problem here is that the 3x API *expects* undefs
> to be transformed to empty string (if that is not done, other functions
> break). However, the 3x runtime does a poor job and only translates
> *some* undefs to empty strings.
>
> We faced a dilemma: which "bug" should future parser be compliant with?
> We choose the strict; translate all undefs to empty string.
>
> In the 4x function API there is no such transformation. The intent is
> to gradually move functions to the new API on a "most urgent to fix"
> basis.
>
> Until this has been done, one way of solving this is to implement
> bridging function using the new API (if it is named the same as the 3x
> function, it will be chosen instead of the 3x function when using parser
> == future). It can then simply relay the call to the 3x implementation
> (without any transformation).
>
> Tip: If attempting to do this, there may be need to transform other
> values such as types - this because the 3x functions does not understand
> the new type system, and something like File['/tmp'] results in a
> PResourceType in the future parser/evaluator, and needs to be
> transformed to a Puppet::Resource.
>
> We are currently discussing, when and how we deal with functions
> that needs to be transitioned to the 4x API. As an interim, maybe we
> should make the future parser bug compatible wrt. transformation of
> undef to empty string when these values are nested in arrays and hashes.
>
> Sorry for the inconvenience.
> Regards
> - henrik
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/a8b19019-2cf3-428b-8d28-4e41e1602899%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
