Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the method APIs more resistant to breaking changes #66

Open
jwodder opened this issue Dec 6, 2023 · 0 comments
Open

Make the method APIs more resistant to breaking changes #66

jwodder opened this issue Dec 6, 2023 · 0 comments
Labels
breaking change Introduction of an incompatible API change method API Relating to the APIs for creating custom methods under consideration Dev has not yet decided whether or how to implement

Comments

@jwodder
Copy link
Owner

jwodder commented Dec 6, 2023

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?
  • 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.

@jwodder jwodder added breaking change Introduction of an incompatible API change method API Relating to the APIs for creating custom methods under consideration Dev has not yet decided whether or how to implement labels Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Introduction of an incompatible API change method API Relating to the APIs for creating custom methods under consideration Dev has not yet decided whether or how to implement
Projects
None yet
Development

No branches or pull requests

1 participant