In a recipe, it is common to have a variable defined in terms of another, with various levels of nesting. Simple Ex: Precondition: ------------- VAR1 ?= "a" VAR2 ?= "${VAR1}b" Triggering Action: ------------------ running Data.getVar over VAR2 in a python script, within a recipe ex: print d.getVar("VAR2") Expected Outcome: ----------------- one would expect that it will yield "ab", just like it would happen if the expansion was performed within a shell script Actual Outcome: --------------- It will instead yield "${VAR1}b", which is somewhat less intuitive and definitely less usable, in typical scenario where one wants to have the final evaluation of the expression. Additional remarks: ------------------- One might argue that this is a feature request, rather than a bug, but I see the current implementation as a deviation from the behaviour of the existing variable expansion performed in shell context. I think it's fair to expect getVar to be the python counterpart of variable retrieval that in a shell is done with "{VAR2}" and therefore I think it should be expected that it behaves in a compatible way.
In the remarks, s/{VAR2}/${VAR2}/
Try d.getVar("VAR2", True) There is an open bug about changing to expand by default but that is a long process. In the current cycle we will make the expand parameter mandatory (we've already done a few rounds of cleanup adding the missing parameters).
Yes, thanks, it worked. I was looking at the wrong code, where the value was already set to True, so I couldn't figure out what else I could do. But this issue can be closed.
Resolved as variable expansion does work.