Delayed task generation: dependencies don't work if tasks are generated in "wrong" order

[felixfontein]

Consider this modified and simplified version of the delayed task generation example:

from doit import create_after

@create_after(executed='early', target_regex='.*\.html')
def task_build1():
    yield {
        'name': 'b.html',
        'actions': ['cp %(dependencies)s %(targets)s'],
        'file_dep': ['b'],
        'targets': ['b.html'],
        'clean': True,
    }

@create_after(executed='early', target_regex='.*')
def task_build2():
    yield {
        'name': 'b',
        'actions': ['touch %(targets)s'],
        'file_dep': [],
        'targets': ['b'],
        'clean': True,
    }

def task_early():
    """a task that create some files..."""
    return {
        'actions': [],
        'targets': [],
        'clean': True,
    }

For me, this always fails with

me@machine: ~$ doit
.  build1:b.html
cp: cannot stat 'b': No such file or directory
########################################
TaskFailed - taskid:build1:b.html
Command failed: 'cp b b.html' returned 1


cp: cannot stat 'b': No such file or directory

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[schettino72]

I guess there is a warning on docs about this...

[felixfontein]

I didn't find a warning (or overlooked it ;) ). But does that mean this behavior is "intended" and probably won't change?

[schettino72]

Sorry, it is actually in the code not in docs: https://github.com/pydoit/doit/blob/master/doit/control.py#L113

As it say FIXME, this behavior is not really intended. The problem is that the implementation has a dictionary mapping targets to tasks. But not of file_dep to tasks. So there would be possible big performance regression in case this is fixed...

Can't you write:

@create_after(executed='build2', target_regex='.*\.html')
def task_build1():

[schettino72]

this is actually a duplicate of #127. Wont fix. added a note to docs.