Re: [Puppet Users] RFE Proposal: lookup_options in the manifest

2019-12-12 Thread Henrik Lindberg

On 2019-12-12 02:59, Alan Evans wrote:
I love Automatic Parameter Lookup (APL) and hiera in general.  But one 
thing I have found awkward is that `lookup_options` are found in the 
hiera data.  In general the idea is to separate data from code right?


Exactly, and that is why the options should be in the data because that 
is the place where data structure was defined!


As an example you may not want to have merging at all and override
a value with a complete hash. You don't want to change a manifest to do 
that.


Lookup options do not feel like data to me, but more like something I 
would find in the code the same way in the code I can type class parameters.

> *Proposal*

Create a data type (or function perhaps that returns a data type) that 
tells the APL code HOW to do the lookup.  The lookup key is just the 
class/name of the current param and the rest of the arguments could 
behave like lookup().


|
classfroboz(
Array[String]$my_param =LookupOptions('unique'),
Hash         $options 
=LookupOptions('deep',knockout_prefix=>'-',default_value=>undef),

){# Do Useful Stuff}
|

Or maybe just *Lookup* with a capital *L* or perhaps a function 
*lookup_options()* that returns some internal class/data type that need 
not be visible to the puppet user.


|
classbozfro(
   $some_param =Lookup(Array[String],'unique',undef),
   $another_param =lookup_options(Hash,'deep',{knockout_prefix =>'-'}),
){# Do Useful Stuff}
|



A default value expression is evaluated if there were no data given in 
the manifest and if no data was found when doing a lookup. So, cannot 
use the default value expression to try to influence the lookup as that 
would break the contract of when those are evaluated.



Do you think lookup_options seem out of place in the hiera data?

No they are at the right place.

Would it make more sense as a Data Type or a function() w/ some 
invisible data type that APL uses?


You would then need to invent new syntax.


Does this belong in puppet proper?  Stdlib? (Could it go in stdlib?)

It cannot go into stdlib it would need to be an integral part of the 
language.



You either use APL and stick the options into hiera as needed, or you
do not bind to any APL looked up keys and use an explicit lookup in the
default value expression. If you do that then you can specify the 
options in your manifest.


I recommend using APL.

- henrik


Please discuss.

-Alan

--
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 puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/50a3ed15-92e1-42f4-99e5-833dd3d12710%40googlegroups.com 
.



--

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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/qstq39%244frn%241%40blaine.gmane.org.


[Puppet Users] RFE Proposal: lookup_options in the manifest

2019-12-11 Thread Alan Evans
I love Automatic Parameter Lookup (APL) and hiera in general.  But one 
thing I have found awkward is that `lookup_options` are found in the hiera 
data.  In general the idea is to separate data from code right?  Lookup 
options do not feel like data to me, but more like something I would find 
in the code the same way in the code I can type class parameters.

*Proposal*

Create a data type (or function perhaps that returns a data type) that 
tells the APL code HOW to do the lookup.  The lookup key is just the 
class/name of the current param and the rest of the arguments could behave 
like lookup().

class froboz(
  Array[String] $my_param = LookupOptions('unique'),
  Hash  $options  = LookupOptions('deep', knockout_prefix=>'-', 
default_value=>undef),
) {# Do Useful Stuff}

Or maybe just *Lookup* with a capital *L* or perhaps a function 
*lookup_options()* that returns some internal class/data type that need not 
be visible to the puppet user.

class bozfro(
  $some_param= Lookup(Array[String], 'unique', undef),
  $another_param = lookup_options(Hash, 'deep', {knockout_prefix => '-'}),
) {# Do Useful Stuff}

Do you think lookup_options seem out of place in the hiera data?
Would it make more sense as a Data Type or a function() w/ some invisible 
data type that APL uses?
Does this belong in puppet proper?  Stdlib? (Could it go in stdlib?)

Please discuss.

-Alan

-- 
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/50a3ed15-92e1-42f4-99e5-833dd3d12710%40googlegroups.com.