pydoit / doit

CLI task management & automation tool
http://pydoit.org
MIT License
1.87k stars 175 forks source link

Feature request: Reverse dependency #432

Closed martin-eder-zeiss closed 2 years ago

martin-eder-zeiss commented 2 years ago

Hi pydoit team,

we are currently trying to adopt doit into our environment, but it is missing a feature that is quite important for us.

It would be nice if there was a way to define a task in its dictionary as a dependency of another task.

Use case: We have a tool that performs checks depending on its configuration file. The creation of the configuration file is divided among a dynamic amount of tasks defined in several Python packages.

The idea was to import only the tasks that are relevant to the specific case. This means that the set of tasks that generate the configuration file is dynamic and cannot be defined statically in a task group.

The problem that arises now is that there is no task group to wait for to determine if the configuration file has been completely created. A solution to this problem would be if task dependencies could be defined in reverse direction, because then tasks could add themselves to a task group.

def task_base_generating_task1():
    return {"actions": None}

def task_base_generating_task2():
    return {"actions": None}

def task_task_group():
    return {"actions": None,
            "task_dep": ["base_generating_task1", "base_generating_task2"]}

def task_consuming_task():
    return {"actions": None,
            "task_dep": ["task_group"]}

def task_additional_generating_task():
    return {"actions": None,
            "reverse_task_dep": ["task_group"]}

Expected graph:

graphviz

schettino72 commented 2 years ago

dup of #151

Reverse dependency creates a bunch of other problems and complexity.

For your trivial example: I guess if I were to implement it I guess I would use a decorator to record this reverse_dep instead of messing with task_metadata.

The idea was to import only the tasks that are relevant to the specific case. This means that the set of tasks that generate the configuration file is dynamic and cannot be defined statically in a task group.

If it is really dynamic (different from your example): doit already has some features that allows dynamic task creation/configuration. Have you looked at calc_dep and @create_after ?

If you show me a real example where current features are not enough for your workflow I would consider it...