Closed martin-eder-zeiss closed 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...
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.
Expected graph: