<commit_before>
* 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.

* Deal properly with an action or composite that has no __init__. Error.

* Ensure that morepath directives get registered before we start using them
  in imports.

* Directives have documentation that shows up in the sphinx docs

* Implement scanning using recursive import.

* if multiple directives declare different classes for the configuration
  registry that should be an error.

* There's another use case to apply the action to the app, not to
  app.registry directly: the logging functionality needs this
  information. I've worked around it now with a hack that sets up the
  app as an attribute on the registry after the fact...

* Support configuration isolation: re-run configuration multiple times.

* Determine that two toplevel directives are actually the same one by
  looking at line number information.

* Support querying the registration database to see what directives
  have been applied. Should this be the registration data or should it
  be based around directives?

* config.py's understanding of '.config/.dectate' is not ideal.

* Refuse to support classmethod & staticmethod? Or refuse to support
  methods?

* the implicit list of global configurables can be reset for testing
  purposes.

* Configure logger by directive directive?

* 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? (done)

* should also do the above for action classes defined by base classes
  and not used. (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.

* group_class used to fill in action classes for those (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.

<commit_msg>More ideas.<commit_after>
* 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.

* Deal properly with an action or composite that has no __init__. Error.

* Ensure that morepath directives get registered before we start using them
  in imports.

* Directives have documentation that shows up in the sphinx docs

* Implement scanning using recursive import.

* if multiple directives declare different classes for the configuration
  registry that should be an error.

* There's another use case to apply the action to the app, not to
  app.registry directly: the logging functionality needs this
  information. I've worked around it now with a hack that sets up the
  app as an attribute on the registry after the fact...

* Support configuration isolation: re-run configuration multiple times.

* Determine that two toplevel directives are actually the same one by
  looking at line number information.

* Support querying the registration database to see what directives
  have been applied. Should this be the registration data or should it
  be based around directives?

* config.py's understanding of '.config/.dectate' is not ideal.

* Refuse to support classmethod & staticmethod? Or refuse to support
  methods?

* the implicit list of global configurables can be reset for testing
  purposes.

* Configure logger by directive directive?

* 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? (done)

* should also do the above for action classes defined by base classes
  and not used. (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.

* group_class used to fill in action classes for those (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.


{'fraction_non_alphanumeric': 0.04243475086694652, 'fraction_numerical': 0.0, 'mean_word_length': 4.075961093098657, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1248058', 'n_tokens_mistral': 2730, 'n_tokens_neox': 2645, 'n_words': 1640}