Verby was originally written to implement the backend of an installer.

An installer conceptually has two inputs, which are combined to get the job done.

The first is the user's configuration (regardless of how it's provided) - the parameters to influence the installation, and the second is the recipe for the actual execution of the installation, a sort of template if you will, that the configuration fills in.

Verby defines the two concepts (not only for installers), and provides some useful code to get them working.

In spirit it's very similar to Makefiles, except that the data involved are mentally closer to Perl than they are to sh(1).

There is a tree of dependant steps, which will all be executed when necessary and possible.

By adding a step to a dispatcher, all it's dependencies are traversed and added too.

Any step that is inserted is immediately asked whether it is_satisfied.

Subsequently "do_all" in Verby::Dispatcher is called. Dependencies are resolved, and any step that has no dependencies, and has not yet claimed it's satisfied is executed.

Every step gets it's own context to play around in. This context persists between invocations of all the methods.

A step which provides_cxt is a special case: Instead of deriving the global context generated for the whole run, an intermediate context is derived first, and then that step's context is derived from the intermediate one. Any step which depends on this step, will have it's context derived from the intermediate context too.

When writing actions to back steps up make sure they will fail properly. For example, missing fields in verify might be due to the fact that some step did not export a necessary field yet. In this case verify should just return false, and will be asked again in due time.

Actions should be short and sweet, doing as little as possible. Remember that a step being a delegator for actions is not limited to using only one action, so if you need to combine procedures, still try to refactor them.

Long running steps, especially ones which drive external processes, like ones using Verby::Action::Run should be asynchroneous. This allows non-interdependant steps to be executed in parallel.

Actions should minimize partial side effects. Transactional behavior is desired for the incremental process to be robust. Ideally the do part of an action will undo previous runs, and the verify part will only be true if the side effect is marked as consistent.

Context fields should be exported from the verification stage, because sometimes a step will not be executed. If execution is necessary to figure out a field that may be exported, then verification should be false.