remove kwargs

[ericbuckley]

Description

Removing kwargs from Algorithm, in favor of explicit definitions of the necessary fields. Additionally, a large refactor of the Algorithm parameter sent to linkage, this is now an instance schema.Algorithm not model.Algorithm.

Related Issues

closes #223

Additional Notes

• Evaluation Context a new section in the Algorithm configuration was created for capturing context parameters. This is very similar to how the existing kwargs functioned, but a) adds structure b) is defined once per Algorithm rather than once per pass.
• Removing rule function since the removal of dibbs-basic, there is only one evaluation rule. It's been removed from the configuration, since it can no longer be configured.
• Making evaluator function name easier the inclusion of the "func:..." syntax was to allow for some flexibility in testing the phdi code against RecordLinker. That flexibility is no longer needed, and using an enum name rather than a function path string seems easier for users to grasp. (ie, users should have to know or care where the function lives in the codebase).
• Swap models.Algorithm for schemas.Algorithm Theres a one way relationship between schemas and models, the former knows about the latter, but not the other way around (necessary to prevent circular imports). This has created some problems when passing models.Algorithm around in the linkage code, for instance we always have to convert a blocking key id/string to a BlockingKey object for evaluation, same goes for Feature. The schemas class has everything we need for parsing the data into the appropriate objects for evaluation, it made a lot of sense and reduced some of the logic needed in recordlinker/linking by making this switch.
• Removing models.AlgorithmPass. Some of the validation logic was being duplicated in the schemas.Algorithm and models.Algorithm, additionally, any time we use the Algorithm, we always want to take a look at the passes. We're already using JSON heavily to store elements of the configuration, so just leaning more into this strategy for storing the passes.

<--------------------- REMOVE THE LINES BELOW BEFORE MERGING --------------------->

Checklist

Please review and complete the following checklist before submitting your pull request:

• I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
• I have reviewed my changes to ensure they are clear, concise, and well-documented.
• I have updated the documentation, if applicable.
• I have added or updated test cases to cover my changes, if applicable.
• I have minimized the number of reviewers to include only those essential for the review.

Checklist for Reviewers

Please review and complete the following checklist during the review process:

• The code follows best practices and conventions.
• The changes implement the desired functionality or fix the reported issue.
• The tests cover the new changes and pass successfully.
• Any potential edge cases or error scenarios have been considered.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.11%. Comparing base (f6cc2d2) to head (37b535d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #249      +/-   ##
==========================================
+ Coverage   97.80%   98.11%   +0.30%     
==========================================
  Files          33       32       -1     
  Lines        1731     1697      -34     
==========================================
- Hits         1693     1665      -28     
+ Misses         38       32       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.