class invoke.config.Config(overrides=None, defaults=None, system_prefix=None, user_prefix=None, project_home=None, runtime_path=None, defer_post_init=False)

Invoke’s primary configuration handling class.

See Configuration for details on the configuration system this class implements, including the configuration hierarchy. The rest of this class’ documentation assumes familiarity with that document.


Configuration values may be accessed and/or updated using dict syntax:


or attribute syntax:

Nesting works the same way - dict config values are turned into objects which honor both the dictionary protocol and the attribute-access method:


A note about attribute access and methods

This class implements the entire dictionary protocol: methods such as keys, values, items, pop and so forth should all function as they do on regular dicts. It also implements new config-specific methods such as load_files, load_collection and clone.


Accordingly, this means that if you have configuration options sharing names with these methods, you must use dictionary syntax (e.g. myconfig['keys']) to access the configuration data.


At initialization time, Config:

  • creates per-level data structures
  • stores levels supplied to __init__, such as defaults or overrides, as well as the various config file paths/prefixes
  • loads system, user and project level config files, if found

At this point, Config is fully usable, but in most real-world use cases, the CLI machinery (or library users) do additional work on a per-task basis:

  • the result of CLI argument parsing is applied to the overrides level
  • a runtime config file is loaded, if its flag was supplied
  • the base config is cloned (so tasks don’t inadvertently affect one another)
  • per-collection data is loaded (only possible now that we have a task in hand)
  • shell environment data is loaded (must be done at end of process due to using the rest of the config as a guide for interpreting env var names)

Any modifications made directly to the Config itself (usually, after it has been handed to the task or other end-user code) end up stored in their own (topmost) config level, making it easy to debug final values.

Finally, any deletions made to the Config (e.g. applications of dict-style mutators like pop, clear etc) are tracked in their own structure, allowing the overall object to honor such method calls despite the source data itself not changing.

Special class attributes

The following class-level attributes are used for low-level configuration of the config system itself, such as which file paths to load. They are primarily intended for overriding by subclasses.

  • prefix: Supplies the default value for file_prefix (directly) and env_prefix (uppercased). See their descriptions for details. Its default value is "invoke".

  • file_prefix: The config file ‘basename’ default (though it is not a literal basename; it can contain path parts if desired) which is appended to the configured values of system_prefix, user_prefix, etc, to arrive at the final (pre-extension) file paths.

    Thus, by default, a system-level config file path concatenates the system_prefix of /etc/ with the file_prefix of invoke to arrive at paths like /etc/invoke.json.

    Defaults to None, meaning to use the value of prefix.

  • env_prefix: A prefix used (along with a joining underscore) to determine which environment variables are loaded as the env var configuration level. Since its default is the value of prefix capitalized, this means env vars like INVOKE_RUN_ECHO are sought by default.

    Defaults to None, meaning to use the value of prefix.

__init__(overrides=None, defaults=None, system_prefix=None, user_prefix=None, project_home=None, runtime_path=None, defer_post_init=False)

Creates a new config object.

  • defaults (dict) – A dict containing default (lowest level) config data. Default: global_defaults.
  • overrides (dict) – A dict containing override-level config data. Default: {}.
  • system_prefix (str) –

    Base path for the global config file location; combined with the prefix and file suffixes to arrive at final file path candidates.

    Default: /etc/ (thus e.g. /etc/invoke.yaml or /etc/invoke.json).

  • user_prefix (str) –

    Like system_prefix but for the per-user config file. These variables are joined as strings, not via path-style joins, so they may contain partial file paths; for the per-user config file this often means a leading dot, to make the final result a hidden file on most systems.

    Default: ~/. (e.g. ~/.invoke.yaml).

  • project_home (str) – Optional directory path location of the currently loaded Collection (as loaded by Loader). When non-empty, will trigger seeking of per-project config files in this location + invoke.(yaml|json|py).
  • runtime_path (str) –

    Optional file path to a runtime configuration file.

    Used to fill the penultimate slot in the config hierarchy. Should be a full file path to an existing file, not a directory path, or a prefix.

  • defer_post_init (bool) –

    Whether to defer certain steps at the end of __init__.

    Specifically, the post_init method is normally called automatically, and performs initial actions like loading config files. Advanced users may wish to call that method manually after manipulating the object; to do so, specify defer_post_init=True.

    Default: False.


Return a copy of this configuration object.

The new object will be identical in terms of configured sources and any loaded (or user-manipulated) data, but will be a distinct object with as little shared mutable state as possible.

Specifically, all dict values within the config are recursively recreated, with non-dict leaf values subjected to copy.copy (note: not copy.deepcopy, as this can cause issues with various objects such as compiled regexen or threading locks, often found buried deep within rich aggregates like API or DB clients).

The only remaining config values that may end up shared between a config and its clone are thus those ‘rich’ objects that do not copy.copy cleanly, or compound non-dict objects (such as lists or tuples).


A Config subclass that the new clone should be “upgraded” to.

Used by client libraries which have their own Config subclasses that e.g. define additional defaults; cloning “into” one of these subclasses ensures that any new keys/subtrees are added gracefully, without overwriting anything that may have been pre-defined.

Default: None (just clone into another regular Config).

Returns:A Config, or an instance of the class given to into.
Raises:TypeError, if into is given a value and that value is not a Config subclass.
static global_defaults()

Return the core default settings for Invoke.

Generally only for use by Config internals. For descriptions of these values, see Default configuration values.

Subclasses may choose to override this method, calling Config.global_defaults and applying merge_dicts to the result, to add to or modify these values.


Update collection-driven config data.

load_collection is intended for use by the core task execution machinery, which is responsible for obtaining collection-driven data. See Collection-based configuration for details.


Load any unloaded/un-searched-for config file sources.

Specifically, any file sources whose _found values are None will be sought and loaded if found; if their _found value is non None (e.g. True or False) they will be skipped. Typically this means this method is idempotent and becomes a no-op after the first run.


Load values from the shell environment.

load_shell_env is intended for execution late in a Config object’s lifecycle, once all other sources (such as a runtime config file or per-collection configurations) have been loaded. Loading from the shell is not terrifically expensive, but must be done at a specific point in time to ensure the “only known config keys are loaded from the env” behavior works correctly.

See Environment variables for details on this design decision and other info re: how environment variables are scanned and loaded.


Merge all config sources, in order.


An iterable of all successfully loaded config file paths.

No specific order.


Call setup steps that can occur immediately after __init__.

May need to be manually called if __init__ was told defer_post_init=True.

class invoke.config.DataProxy

Helper class implementing nested dict+attr access for Config.

Specifically, is used both for Config itself, and to wrap any other dicts assigned as config values (recursively).


All methods (of this object or in subclasses) must take care to initialize new attributes via self._set(name='value'), or they’ll run into recursion errors!


list of weak references to the object (if defined)

classmethod from_data(data, root=None, keypath=None)

Alternate constructor for ‘baby’ DataProxies used as sub-dict values.

Allows creating standalone DataProxy objects while also letting subclasses like Config define their own __init__ without muddling the two.

  • data (dict) – This particular DataProxy’s personal data. Required, it’s the Data being Proxied.
  • root – Optional handle on a root DataProxy/Config which needs notification on data updates.
  • keypath (tuple) – Optional tuple describing the path of keys leading to this DataProxy’s location inside the root structure. Required if root was given (and vice versa.)

Return a fresh copy of source with as little shared state as possible.

Uses merge_dicts under the hood, with an empty base dict; see its documentation for details on behavior.

invoke.config.excise(dict_, keypath)

Remove key pointed at by keypath from nested dict dict_, if exists.

invoke.config.merge_dicts(base, updates)

Recursively merge dict updates into dict base (mutating base.)

  • Values which are themselves dicts will be recursed into.
  • Values which are a dict in one input and not a dict in the other input (e.g. if our inputs were {'foo': 5} and {'foo': {'bar': 5}}) are irreconciliable and will generate an exception.
  • Non-dict leaf values are run through copy.copy to avoid state bleed.


This is effectively a lightweight copy.deepcopy which offers protection from mismatched types (dict vs non-dict) and avoids some core deepcopy problems (such as how it explodes on certain object types).

Returns:The value of base, which is mostly useful for wrapper functions like copy_dict.
invoke.config.obliterate(base, deletions)

Remove all (nested) keys mentioned in deletions, from base.