> 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"]))
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.
-- Markus
--
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.
