Idea: Require method implementations to be subclasses of base classes defined by versioningit, one base class per step. Instances of these classes will have step arguments provided as instance attributes (and thus additions to the arguments should not require updating any code), and they are executed via a run() or __call__() method.
-
Other possible instance attributes of method classes:
- the path to the project root
- the complete
versioningit configuration? (before or after processing by Config.parse_*?)
- a
Versioningit instance?
- a
dict in which plugins can store arbitrary data (keyed by plugin name) that is then passed to subsequent steps so that multiple plugins from the same package can share state
-
Possible ways to supply the user parameters:
- As a dict passed to the
run() method
- As a dict attribute on instances
- A method class could then validate user parameters at construction (which happens while parsing the configuration, before execution) by overloading
__init__.
-
Cf. Hatch's plugin classes
-
Problem: This won't address the need to make breaking changes to do_STEP() methods whenever a new argument is added.
Idea: Require method implementations to be subclasses of base classes defined by
versioningit, one base class per step. Instances of these classes will have step arguments provided as instance attributes (and thus additions to the arguments should not require updating any code), and they are executed via arun()or__call__()method.Other possible instance attributes of method classes:
versioningitconfiguration? (before or after processing byConfig.parse_*?)Versioningitinstance?dictin which plugins can store arbitrary data (keyed by plugin name) that is then passed to subsequent steps so that multiple plugins from the same package can share statePossible ways to supply the user parameters:
run()method__init__.Cf. Hatch's plugin classes
Problem: This won't address the need to make breaking changes to
do_STEP()methods whenever a new argument is added.