fabric/fabric — Issue #452: Task dependencies?
Author: bitprophet
Created: 2011-10-13 21:46:14+00:00
State: open
Labels: 1.x, Core, Feature

1.3 features `execute()` which allows for meta-tasks which call other tasks and honors their individual `@hosts`, etc settings. This solves many of the more complicated multi-task invocation problems people have run into.

However, there are some arguments in favor of having a flipped-around version of a meta-task, namely specifying that Task A should always execute Task B before or after it runs. (Versus creating a Task C consisting solely of `execute(Task B); execute(Task A)`.) This is commonly referred to as "dependencies" or a "call chain", as seen in Rake/Capistrano/etc.

I'm not 100% convinced that a implicit/magical dependency-chain solves any use cases *not* solved by meta-tasks, or that the syntax/code/number-of-tasks savings* is worth the potential for confusion or increased (internal) code complexity.

However it's worth having a discussion on it because it is a common design pattern in similar tools and comes up frequently.

----

Closely related: the idea of having a queue instead of a loop in `fabric.main.main`, as mentioned in #391. In such a system, dependency decorators might act by simply loading the referenced items into the queue before/after the decorated task, at the time it is to be added by `fabric.main.

----

\* Meta-tasks do require an extra couple lines of code in the simplest use cases, versus a single decorator line on one of the subtasks; and they require more task names to be thought of / remembered / communicated to others ("No, don't run `deploy`, run `full_deploy` instead!" etc)