Updated tester schema generation to use msgspec data types #689
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a first step to using data types to represent tester settings. Currently tester settings are read in as JSON, and then wrapped in the
TestSpecsclass, which acts like a dictionary. Introducing data types allows for more robust verification of the data types and to leverage static analysis tools (e.g. in IDEs, typecheckers) when developing.This PR accomplishes two main steps:
schema.pyfile that contains msgspec struct definitions for the tester settings, leveraging the base definitions in markus-autotesting-core.setup::settingsfunction to use the new structs rather than the existingsettings_schema.jsonskeletons.The result is a new JSON schema for the autotester that is functionally equivalent to the previous schema, but is now derived from the new structs. In the future, we can modify the testers themselves to decode the settings JSON into the structs, allowing us to refactor the code to use the new data types instead of the dict-like
TestSpecsclass.This PR builds on @ch-iv's work in #599.
[1] With the exception of the AI and PyTA testers. The former's specification is still subject to change, and the latter is planned to be deprecated, so I didn't include them in this refactoring.