On 12/02/10 19:20, Markus Roberts wrote:
>> Is it stable enough that I can pull testing and base the Hash stuff on
>> it?
>>
>
> That's a good question. It's semi-stable, but it's also a moving target.
> I'm going to be pushing a revised/cleaned up version in the next day or so,
> Luke is going to be sliding his work on #2954 in right before it (probably
> later today), and I'm going to rebase the string interpolation patch on top
> of it and add that as well.
>
> Glancing over your patch, the areas we'll need to address seem to be:
>
> * if you apply to the present end of testing, safeevaluate no longer takes a
> scope parameter
> * If you apply after my full change sequence, evaluate and evaluate_match
> will no longer take scopes as well
> * AST node creation now takes a :scope => s option
> * Lookupvar gets replaced with a two step sequence (find the future and get
> it's value):
>
> @scope.stubs(:lookupvar).with("a").returns(["b"])
>
> becomes something like:
>
> @scope.stubs(:future_for).with("a").returns(stub('future_a',:value =>
> ["b"]))
Yes, I was aware of this as I read your patch in testing.
> This is the core of the change; splitting variable access into determining
> what we are talking about (the name & scoping part) and a separate
> determination of that variable's value gives us objects we can talk about,
> pass around, store, etc. before their values are known.
>
> * setvar is more complicated; my original ad hoc solution doesn't work
> cleanly on the present code base and I'm still playing with alternatives;
> basically in needs to find the future .
> * There are some subtle ordering issues that you need to keep in mind while
> writing tests. For example, the _name_ of a variable is a value in our
> system (a string), and (unlike other values) this needs to be resolvable at
> the time a VarDef is created. In puppet code this shouldn't be an issue
> (variable names are given literally) but in writing tests you need to make
> sure that the scope->future_for->value chain for the variable is set up
> before you create a VarDef
>
> Options at this point:
>
> * rebase onto the present end of testing
> * wait until Luke's branch merges cleanly and my stuff (including string
> interpolation) is stabler
> * rebase onto a commit right before the futures stuff (such as
> b4e4de350a51bc1b362cc7d134d86daa33a99765) and making dealing with the issues
> listed above it my problem (this is the option Luke is taking with his #2954
> stuff)
>
> Any of these is fine with me, though I'd prefer the first or the third on
> the principle of getting stuff in early so we can resolve the conflicts.
For simplicity I'd like 3), but I need your string interpolation patch,
so I guess that'd be 2). But that doesn't mean I can rebase now and try
it for fun.
Does your future stuff works only for variable value, or does it also
covers resources (it doesn't seem so)?
I'm asking this question, because when I first submitted the hashes
patch, one of Luke's comment was to also support getting resource
parameters through the same syntax (which fired the start of your future
work).
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
