Issue #6745 has been updated by konrad rzentarzewski.

same problem with defines and passing undefs to native types.

i work around it with checking if variable is empty and then setting it undef 
when calling parameters.

ie.

    define foo ($owner=undef,$mode=undef) {
     # skipped logic setting variable copies owner_c and mode_c depending on bar
    
     file { $title:
      # skipped irrelevant file params
    
      owner => $owner_c ? { /.+/ => $owner_c, default => $owner ? { /.+/ => 
$owner, default => undef } },
      mode => $mode_c ? { /.+/ => $mode_c, default => $mode ? { /.+/ => $mode, 
default => undef } },
     }
    }

sweet :)
----------------------------------------
Bug #6745: Puppet needs a better undef/way to handle nil's from custom functions
https://projects.puppetlabs.com/issues/6745

Author: Rich  Rauenzahn
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


It appears to me that undef isn't really a real type in puppet.  If I pass 
something that is undef to a custom function and ask Ruby for its class, it 
says it is a String.  It almost seems like undef is just an alias for "".  It 
would be nice if it was a distinct type.

More importantly (see farther below), nil bubbled up from Ruby code ought to be 
evaluated correctly within puppet.

Let's look at the type mappings:

  define test {

    $type1 = vmw_type("") # this func returns foo.class.to_s
    notice("string is $type1")

    $array = ["a", "b"]
    $type2 = vmw_type($array)
    notice("array is $type2")

    $dict = { "key" => "value" }
    $type3 = vmw_type($dict)
    notice("dict is $type3")

    $bool = true
    $type5 = vmw_type($bool)
    notice("true is $type5")

    $undef = undef
    $type4 = vmw_type($undef)
    notice("undef is $type4")
  }

  test { "foo": }

  [rich@rich-fedora tests]$ puppet --modulepath=/Perforce     
/main/machines/puppet/puppetmaster/modules/ tests/vmw_type.pp 
  notice: Scope(Test[foo]): string is String
  notice: Scope(Test[foo]): array is Array
  notice: Scope(Test[foo]): dict is Hash
  notice: Scope(Test[foo]): true is TrueClass
  notice: Scope(Test[foo]): undef is String

So either undef is really a string, or it was evaluated to a string before 
being passed to the custom function.

Related, when a custom function returns a nil, puppet doesn't know what to do 
with it at all, and I think that nil ought to be mapped to this undef type:

  [rich@rich-fedora tests]$ puppet 
--modulepath=/Perforce/main/machines/puppet/puppetmaster/modules/ 
vmw_json_parse.pp 

  [...]
    $foo3 = vmw_json_parse("bad|,'':") # this just calls the PSON parse, 
returns nil if fails to parse.

    $type = vmw_type($foo3)
    notice("type=$type")

    if $foo3 == "" { notice("foo3 is ''") }
    if $foo3 == undef { notice("foo3 is undef") }
    if !$foo3 { notice("foo3 is not true") }
    if $foo3 { notice("foo3 is true") }

  [...]

The output below shows that NilClass is not an empty string, or is it undef, 
but is in fact true.

  notice: Scope(Test[a]): type=NilClass
  notice: Scope(Test[a]): foo3 is true

Now, we could have puppet walk dictionaries, arrays, and scalars returned from 
custom functions and transform nil scalars into "" (or undef), but it would 
seem smarter to change the internal guts of puppet to treat NilClass as undef 
(is there really any such thing as undef in the internal code?  Or is it really 
just an alias for ""?)

So, in summary:

(a) Puppet should handle nils returned from custom functions
(b) Would this be a good time to also map undef to a ruby data type, like nil?



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

Reply via email to