Generate schema with pydantic v2

[bmaranville]

Using pydantic v2.x, we can use a TypeAdapter to convert stdlib dataclasses to a pydantic model, which we can then use to generate a schema.

This removes the need to use pydantic dataclasses, and therefore we don't need the indirect import of the dataclass decorator from a central location (which was previously monkey-patched when generating the schema)

I ran across an issue with the Column.unit attribute: in the old schema generator, a constraint was manually added to that attribute at schema-generation time which restricted the value to one of ["1/angstrom", "1/nm", "1", "1/s", None], which is ok for the Qz and R columns but which won't work for additional columns like wavelength (see #125)

For the moment I replicated the old behavior, with a note that it needs to be changed (existing tests all pass right now)

[bmaranville]

It looks like the version of jsonschema pulled in to python 3.6 doesn't have a validator for metaschema version 2020-12 https://json-schema.org/draft/2020-12/schema , which is causing tests for that version of python to fail.

[andyfaff]

It seems that Pydantic V2 only supports Python3.7 and above, https://pypi.org/project/pydantic/2.0/#files.

Possible workarounds include:

• disable the test for Python 3.6.
• bump the minimum Python version to 3.7. (note that the final security fix for Python3.6 was 3 years ago).

I have a preference for the latter option but could live with the former. At some point we're going to have to bump Python versions.

[andyfaff]

Otherwise I think this PR is mergeable.

I wonder if we can actually remove the generated yaml and json schemas from the repository? Having them present will lead to churn as they seem to change frequently. Instead we could add a build step in which the schemas are generated. When wheels are generated the schemas will be present in the package.

[andyfaff]

Concerning the column units. I think there is no actual solution in a schema that would allow some units to be checked and others not. I personally would prefer to keep the schema the same as the class hint and to add an additional check to the validation code we use.

So allow any string for units in the schema, and add extra code to _validate_header_data to check the first four columns?

[andyfaff]

Last commit alters the validation function to emit a ORSOSchemaWarning for cp36.

[andyfaff]

All tests pass now (except the coverage aspect), so merging. Thanks everyone.