I would also like to propose that we use the metaparameter syntax for
defaults as well.
For example, rather than writing this:
#less readable
file {
default:
mode => '0666';
'/tmp/foo': ;
'/tmp/bar': ;
'/tmp/special':
mode => '0777';
}
One would write this:
#more readable
$defaults = {
ensure => file,
mode => '0666',
}
file { [ '/tmp/foo', '/tmp/bar' ]:
attribute_defaults => $defaults,
}
file { '/tmp/special':
mode => '0777',
attribute_defaults => $defaults,
}
The benefits to that approach are that it looks & feels more like the
Puppet language, it's less of a conceptual change going forward, and
it's also easily searchable. It's also possible have multiple default
hash variables in scope and just assign them as needed.
On Wed, Aug 6, 2014 at 5:15 PM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
> On 2014-07-08 1:18, Wil Cooley wrote:
>
>> On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg
>> <henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
>>
>> wrote:
>>
>> $extra_opts = { $ssl => true, ... }
>>
>>
>> I assume you mean {ssl => true, ...}, and not the value of a
>> variable $ssl ?
>>
>>
>> Yes, sorry
>>
>>
>> apache::vhost { ...
>> ssl => undef,
>> attributes => $extra_opts,
>> }
>>
>>
>>
>>
>> And:
>>
>> $extra_opts = { $ssl => undef, ... }
>> apache::vhost { ...
>> ssl => true,
>> attributes => $extra_opts,
>> }
>>
>> Both of these results in an error, you are not allowed to set ssl
>> twice (most likely a mistake).
>>
>>
>> I think I trimmed too much context; Reid had proffered two behaviors and
>> I was responding to the first:
>>
>> Example 1 (assuming behavior whereinmerging is OK, and that
>> explicit parameter specification takes precedence):
>>
>> ...
>>
>> Example 2 (assuming that merging is not OK, and that conflicts
>> will be treated as duplicate parameter specification):
>>
>> Example 1 can be used to replace/supplement resource defaults; 2 cannot.
>>
>> My expectation is that in both cases 'undef' means "pretend I've
>> said
>> nothing about thus attribute here" and that *true* wins in
>> either case.
>>
>> undef only has a special meaning when it is the final value of the
>> given attribute; it then means "No value specified for this
>> parameter".
>> That is undef behaves as a "value" until the resource creation takes
>> place.
>>
>>
>> I think that amounts to the same thing, but from different sides of the
>> compiler, so to speak.
>>
>> Such as ignoring a resource default:
>>
>> Exec { timeout => 30 }
>>
>> # Bunch of execs that sometimes take too damn long
>>
>> exec { '/usr/bin/sleep 60': }
>>
>> ...
>>
>> # Then another exec that should have the default timeout, but I
>> don't want
>> # to hardcode (or even remember) what that is (i.e. pretend the above
>> # resource default does not exist):
>>
>> exec { '/usr/bin/ping localhost': timeout => undef }
>>
>> Or passing options from a defined type to a type declaration:
>>
>> define filelike($seltype = undef) {
>>
>> file { '/tmp/foo':
>>
>> seltype => $seltype,
>> }
>> }
>>
>> Yes that is how undef works when you are passing arguments to parameters.
>
>
>
>>
>> apache::vhost { $title: **$extra_opts }
>>
>>
>> or:
>>
>> apache::vhost { $title: &$extra_opts }
>>
>> or:
>>
>> apache::vhost { $title: *$extra_opts }
>>
>>
>> So, that was the initial proposal '*' for any name followed by =>
>> and the value. This also looks similar to the unary splat '*' that
>> can be used to unfold an array or hash.
>>
>> That suggestion was not well liked... "no more operators please...".
>>
>>
>> Part of what is bothersome to me about the "* =>" proposal is that it
>> looks like
>> an assignment to a wildcard, which makes my head spin.
>>
>> It would be possible to specify '*' as signaling "here is an
>> attributes hash". The only quirk is that it would be a special
>> syntactic marker that is followed by any expression (which includes
>> splat) - no harm, just slightly odd that you are allowed to write
>> **$extra_opts, where this is not allowed elsewhere (splat is non
>> associative, just like unary minus).
>>
>>
>> Rather than a special construct that only applied for attributes, it
>> could be a
>> general unpacking operator, like it is in Ruby and Python. I guess
>> that's a bigger can of worms.
>>
>> It is already an unpacking operator nicknamed 'splat', hence what I
> wrote above. The problem in the grammar is that there is the need to have a
> syntactic marker, it is impossible to allow any expression at that point.
>
>
> I echo Reid's sentiments about language complexity and prefer the metavar.
>>
>> ok, good, that seems to be what most prefer.
>
> Wil
>>
>> --
>> 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+unsubscr...@googlegroups.com
>> <mailto:puppet-dev+unsubscr...@googlegroups.com>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CAMmm3r5jAUnP0s_
>> rWVqtUqJ4cZjnuCrLLG77XteG0q7rY7W43Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CAMmm3r5jAUnP0s_
>> rWVqtUqJ4cZjnuCrLLG77XteG0q7rY7W43Q%40mail.gmail.com?utm_
>> medium=email&utm_source=footer>.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> 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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/lrugeh%24527%241%40ger.gmane.org.
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Ben Ford | Training Solutions Engineer
Puppet Labs, Inc.
926 NW 13th Ave, Suite #210
Portland, OR 97209
509.592.7291
ben.f...@puppetlabs.com
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CACkW_L6v_HqwAx5eGxXPUkQWi4MxkUeuoeRkrybFfPikHQUv9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
