1

is there a way to make Puppet to differentiate between

my_custom_type { 'key':
  value => 'blah',
}

and

my_custom_type { 'key':
  value => ['blah'],
}

when declaring resource attributes?

this is for a custom type, so i have full ruby-land control, but both show up to Puppet::Type#set_parameters and consequently Puppet::Property#should= as 'blah'.

i'm using Puppet 3.4.3 on top of Ruby 2.0.0 (through Boxen). i'm not sure how easy it would be for me to change either of those versions.

CONTEXT: the custom type I'm implementing edits Apple property lists (.plist files), where a string and an array containing a single string element are quite different.

declaring the property like

newproperty(:value, :array_matching => :all) do

along the lines of

https://docs.puppetlabs.com/guides/custom_types.html#customizing-behaviour

doesn't seem to change what set_parameters or should= receive, they just make Puppet::Property#should return ['blah'] instead of 'blah' in both cases. it appears the differentiation is tossed out further up at the parser level.

providing

my_custom_type { 'key':
  value => [['blah']],
}

doesn't help either - same result.

PLEASE NOTE:

i realize i can work around this by providing additional information in the declaration, like so:

my_custom_type { 'key':
  value => ['blah'],
  is_array => true,
}

or

my_custom_type { 'key':
  value_array => ['blah'],
}

i'm wondering if there is a way to capture whether an array or scalar was declared... though feel free to explain to me why doing so would be unwise or heretic in Puppet-world; i'm a little new to this strange place.

nrser
  • 1,287
  • 1
  • 13
  • 23
  • Sounds like Puppet is trying to be too helpful. Yes, your workarounds will work, but it's unfortunate that your manifest have to contain such redundant information. You might want to consider opening a feature request towards resource types allowing the behavior that you need. – Felix Frank Oct 19 '14 at 18:38
  • @FelixFrank yeah, i can see the parser saying "all resource attributes are arrays" and wrapping values not written as arrays. i would be fine using `[['blah']]`, i can make sense of that and remember it and explain it to others. i can not see why it *pulls apart* `[['blah']]` (and `[[['blah']]]`, etc.) to be equivalent. that makes no sense to me. – nrser Oct 19 '14 at 18:53
  • It might be as simple as an `Array#flatten` call. – Felix Frank Oct 19 '14 at 19:06
  • @FelixFrank yeah, i'm sure it's that simple... i'm just not sure *why* (other than implementation detail side-effect that no one thought of / noticed) – nrser Oct 19 '14 at 19:10
  • I actually think this is happening by design. What's missing here is an `:array_matching` option that will actually do what you need. – Felix Frank Oct 20 '14 at 11:29

1 Answers1

0

The underlying single-element special-casing was deprecated in puppet3, and is not part of the language's behaviour since a long while. See https://tickets.puppetlabs.com/browse/PUP-1299.

David Schmitt
  • 58,259
  • 26
  • 121
  • 165