Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-4016

Consider short circuiting data binding if lookup is called as the default value



    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: PUP 4.0.0
    • Component/s: Compiler
    • Labels:
    • Template:
    • Story Points:


      With the new data provider support (PUP-1640), and the new lookup function (PUP-3948) we have a very good story for how to handle data binding and lookup.

      One feature that is asked for over and over again is the ability to perform automatic data binding of class parameters using other lookup strategies than 'priority'.

      Users try to achieve this by making a call to either hiera_hash or hiera_array and they are then surprised when these functions are not called. What they must do is bind a different key in data (to avoid the automatic lookup, and instead use the default value expression for the parameter.

      A solution to this could be to say that a parameter that has a default value expression that is a call to `lookup` uses this expression instead of the automatic lookup.

      Thus, if a value should use the `unique` (array) strategy, this is declared as:

      class myclass(Array[Integer] $foo = lookup({strategy => unique}) {

      Further, since the lookup allows all its arguments to be given in a hash, the special handling could add any missing parameters from the parameter declaration (in the example, the name of the parameter, and its type).

      The author can naturally also provide a default value - which will kick in if no data binding is found. (And to be complete, if users expresses the default value expression as only lookup() the effect is the same as performing automatic lookup - albeit with a different error message about lookup failing as opposed to value is missing). This later is also an important distinction for two reasons; it indicates that it is intended to pick up values (like default from the module itself (and something is wrong if no value is obtained), and secondly, it looks less magic.

      We can provide the same processing for user defined types, where the missing arguments to lookup are "magically" inserted. That would be a great help to users as they now have to repeat the full name of the parameter.

      We should consider this for 4.0.0 since it is an API breaking feature (behavior is different than if there is no special processing of calls to lookup - but we could handle this with a release note since there is no code that is currently using the new lookup function). I think this is a fairly small change.

      ping Eric Sorenson




            henrik.lindberg Henrik Lindberg
            QA Contact:
            Kurt Wall
            0 Vote for this issue
            3 Start watching this issue



                Zendesk Support