-
Notifications
You must be signed in to change notification settings - Fork 6
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
Class-based architecture for deposition plugins #218
Conversation
5959f6f
to
26a649f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still WIP, but I could not resist to leave some notes already. Thanks for getting this started 😀
Maybe we should also write an ADR about this... now that HEQATE is not coming, we need to ensure quality ourselves 😭 |
Yup, I also thought about writing an ADR and was going to address it at the next JF 😄 |
5e2ef00
to
3d2f8f3
Compare
Mostly entry point → plugin
This makes initializing the resolver with a context obsolete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chore: There are some points that should be changed, but the general idea looks good.
question: Do we want to allow to override single process steps with a custom implementation or does this mean that you need to write yet another plugin (i.e., derive from the class that you want to modify and only adapt the respective part)?
This pull request converts the existing deposition plugins into classes which makes reuse and customization easier and prevents functions from having to load context and config over and over again.