Python "make" like tools (was Re: [ANN] DoIt 0.1.0 Released (build tool))

[Ville M. Vainio]

Eduardo Schettino wrote:

>>  I find the doit syntax a bit cumbersome, especially as you can avoid
>>  'args' by just returning a lamda in 'action'.
> 
> 
> My idea was to: do *not* add any new syntax (to avoid being
> cumbersome). It is just python, you dont have to import or subclass

Yeah, decorators get around this.

> I though about using decorators in the beginning... but returning a
> dictionary looked easier to implement and more flexible. one important
> feature is how easy to define a group of task with the same action.
> Take a look at the example below on running pychecker in all python
> files from a folder. I couldnt figure out an easy way of doing it with
> decorators.
> 
> import glob;
> pyFiles = glob.glob('*.py')
> 
> def task_checker():
>     for f in pyFiles:
>         yield {'action': "pychecker %s"% f,
>                'name':f,
>                'dependencies':(f,)}

Perhaps you could do:

for f in pyFiles:
   @task("checker")
   @depend(f)
   def check():
     c("pychecker %s" % f)

Never underestimate the magic that is nested scopes and name-agnostic 
function object creation...


> Another advantage of using just a dictionary to define a task is that
> it will be easy to read tasks from a text file (if it is very simple
> and you dont need to write any python script). but not implemented
> yet.

It is easy with the above syntax as well.


> I though about using decorator for simple python-tasks but in a different way:
> 
> @task
> def create_folder(path):
>     """Create folder given by "path" if it doesnt exist"""
>     if not os.path.exists(path):
>         os.mkdir(path)
>    return True
> 
> so if your python function is a task and you will use it only once you
> dont need to define a function for the 'action' and another function
> to create the task. but not implement yet also.

Yeah, this is what I consider much friendlier syntax (the aim is to not 
be much more verbose than make).

> apart from one .py file installation (easy_install is not enough?)
> thats what i am trying to do.

easy_install is not really enough - it introduces a dependency that you 
can't get around by just shipping a short .py file with your project.

This problem domain seems simple enough that it should be covered by a 
very short and simple module (Paul, the Waf you suggested was ~ 300k, no 
doubt caused by all the c compiler stuff that I don't need).

'Paver' seems to have the right idea:

http://www.blueskyonmars.com/projects/paver/index.html

But it's still *slightly* too big:

http://bazaar.launchpad.net/~dangoor/paver/main/files