
* Different types of actions need to group together so they
  conflict/override. Currently uses group_key method, renamed to
  group_class for clarity. (Stick to this, as class is needed to sort
  actions by dependency) (done)

* An action has an identifier for conflicts and overrides. Prefixed by
  group key so we don't need to distinguish between actions in
  different groups.(done)

* Extra discriminator list to make more conflicts happen. (done)

* Generate sub-actions instead of performing things directly. This is
  done in prepare right now. (done)

* Directive abbreviations. (done)

* Abbreviated directives should have correct frame info for error
  reporting. (done)

* Do checks on input parameters depending on what object is being
  decorated (class versus function). Done in prepare, such as for path
  directive. Should now move it into perform and raise errors if
  things are wrong. Check on error reporting. (done)

* Dependencies between actions. (done)

* Subclasses of App can have new directives through the directive
  directive (done)

* Prepare now only works one level deep: you can't implement a
  directive as multiple actions which then in turn are actually other
  actions. This has been fixed with Composite actions (done)

* Not use Venusian: a directive should register with the configuration
  system (or better: the App) immediately upon import as it's easier to
  explain. (done)

* We have some use cases where we'd like to execute some code after
  all directives of a particular kind are done executing. This way we
  could initialize the predicates for all external predicates
  functions, for instance. (done)

* Have line number information for error reporting. (done)

* Apps could have multiple independent registries (or at least
  registries APIs; many will build on the reg registry). Perhaps
  actions can somehow declare which registry APIs they concern
  themselves with. This way we could avoid mixing a lot of registry
  mixins into a larger registry. (done)

* The config object should get the configurables explicitly. Or apps?
  And then allow a commit. (done)

* rename to something else as Confidant as now on PyPI. Now dectate. (done)

* Sometimes during prepare it'd be useful to have access to the registry. But
  since prepare is gone, not relevant anymore. (done)

* separate "configurations" object from configurable. (done)

* there's also an implicit list of configurables kept globally (done)

* Directive logging. (done)

* The normal conflict detection will report correctly that there's
  a conflict if a module is imported twice. (done)

* should we store the *directives* on the configurable instead of the
  actions to prevent any user code execution that can do too much? (done)

* but if a module is imported twice and a variable is increased upon
  import that causes a non-conflict, a ConflictError won't be raised...
  How contrived is that scenario? Could happen if you generate information
  dynamically. This is now documented. (done)

* Ensure that morepath directives get registered before we start using them
  in imports. Appears to be not a problem. (done)

* Directives have documentation that shows up in the sphinx docs (done)

* Implement scanning using recursive import. Done in Morepath using
  importscan module. (done)

* Support configuration isolation: re-run configuration multiple times.
  (done)

* Determine that two toplevel directives are actually the same one by
  looking at line number information. Not done: we rely on a different
  mechanism, conflict detection, to detect this now. this is documented.
  (done)

* Refuse to support classmethod & staticmethod? Or refuse to support
  methods? Conclusion: no classmethod, do support staticmethod. (done)

* the implicit list of global configurables can be reset for testing
  purposes. Conclusion: don't allow this as it's useless for testing. (done)

* is it possible to set up the registries before the action group is
  executed? Maybe not, as action group could still contain multiple
  types of action. Unless we make `config` behave like `before` and
  `after`. Or should we simply set up *all* registries, including
  those for directives we never encountered? Should we also do before/after
  for those registries without content? Conclusion: we set up the
  registries for all action groups, and only action group main class
  has a config. (done)

* should also do the above for action classes defined by base classes
  and not used. (done)

* Configure logger by directive directive? This is now done in the App
  base class with logger_name. (done)

* refactor so that action groups are set up *before* the rest of the
  commit, so we don't have to create action groups just in time while
  going through actions. Base it off the action groups we have
  registered. an action group has a before, after and a config.
  there's a shortcut way to register an action without an action
  group, but an action with both an action group *and* shortcut
  methods is an error. (done)

* the action_classes in setup_config should be sorted so that behavior
  is consistent even if registries are set up inconsistently. (done)

* handle TypeError if action_factory is called with wrong parameters. (done)

* write a test for TypeError handling. (done)

* Registry dependencies:

  a registry can be initialized with another registry as the constructor.

  if the registry is listed it will be used. the other registry must
  be listed in the config *or* be initialized by one of the depends.

  {
     'template_engine_registry': TemplateEngineRegistry, ('settings',)
  }

  Now implemented as factory_arguments. (done)

* rethink the way action groups work; right now they're by action
  class, but the implementation gets confusing as we have the true
  action class used to do the config setup and also the action group
  class used for before/after. Either use the action group class for
  everything, including config setup, or use another mechanism for
  grouping. Done: now the action group is in charge of before, after,
  config. (done)

* group_class for a group_class should be an error. (done)

* if a group_class class defines before or after or config, that should
  be an error. But subclassing it is okay. (done)

* Deal properly with an action or composite that has no
  __init__. Error. Fixed by providing a base __init__.(done)
