Major change I'm considering for options
Kevin Dangoor
has access to all of the options and any change in any of the options
determines whether or not the task will run or has already been run.
I had two thoughts with this approach:
1. duplicating settings is bad, so I wanted the functions to be able
to reach around and grab whatever they want.
2. a task should be able to modify options and call another task
To avoid the general weirdness of using a single global option set
and, at the same time, likely make the model fit a little closer to
zc.buildout's which will help with integration, I'm considering making
'options' a parameter to a task. It is actually possible to do this
optionally, so that tasks can continue working like they do now.
Tasks would be given just the options for their task. However, to take
care of #1 an option can be defined with a template snippet or lambda
that is evaluated just before the task is run. Those will have access
to the complete options, so you can make one setting dependent on
others. Ian Bicking mentioned this as something he does and it sounded
quite handy.
For #2 above, we can just add a function that gets the current set of
options for a task and then you can call_task(taskname, options) to
pass along the options.
I know there's only a handful of us on this list right now, but I
wanted to toss out this proposal to see what people think.
With the distutils integration and especially once the zc.buildout
integration is there as well, I think the value of Paver's model will
become much clearer. Oh, and of course, I'll be fixing the current doc
bug that Ben Bangert pointed out to me which is a high-level "how you
use paver" doc. Oops.
Kevin