invoke.executor.Executor

Initialize executor with handles to necessary data structures. :param collection: A `.Collection` used to look up requested tasks (and their default config data, if any) by name during execution. :param config: An optional `.Config` holding configuration state. Defaults to an empty `.Config` if not given. :param core: An optional `.ParseResult` holding parsed core program arguments. Defaults to ``None``.

Deduplicate a list of `tasks <.Call>`. :param calls: An iterable of `.Call` objects representing tasks. :returns: A list of `.Call` objects. .. versionadded:: 1.0

Execute one or more ``tasks`` in sequence. :param tasks: An all-purpose iterable of "tasks to execute", each member of which may take one of the following forms: **A string** naming a task from the Executor's `.Collection`. This name may contain dotted syntax appropriate for calling namespaced tasks, e.g. ``subcollection.taskname``. Such tasks are executed without arguments. **A two-tuple** whose first element is a task name string (as above) and whose second element is a dict suitable for use as ``**kwargs`` when calling the named task. E.g.:: [ ('task1', {}), ('task2', {'arg1': 'val1'}), ... ] is equivalent, roughly, to:: task1() task2(arg1='val1') **A `.ParserContext`** instance, whose ``.name`` attribute is used as the task name and whose ``.as_kwargs`` attribute is used as the task kwargs (again following the above specifications). .. note:: When called without any arguments at all (i.e. when ``*tasks`` is empty), the default task from ``self.collection`` is used instead, if defined. :returns: A dict mapping task objects to their return values. This dict may include pre- and post-tasks if any were executed. For example, in a collection with a ``build`` task depending on another task named ``setup``, executing ``build`` will result in a dict with two keys, one for ``build`` and one for ``setup``. .. versionadded:: 1.0

Expand a list of `.Call` objects into a near-final list of same. The default implementation of this method simply adds a task's pre/post-task list before/after the task itself, as necessary. Subclasses may wish to do other things in addition (or instead of) the above, such as multiplying the `calls <.Call>` by argument vectors or similar. .. versionadded:: 1.0

Transform arbitrary task list w/ various types, into `.Call` objects. See docstring for `~.Executor.execute` for details. .. versionadded:: 1.0