Consider switching attrs -> pydantic

[wpbonelli]

As @mwtoews has suggested we can use JSON schema for the DFN specifications (also forthcoming MF6 NetCDF spec and any other schema-related needs). A big benefit of pydantic is built-in JSON schema support . If we continue using attrs we will have to roll our own schema generation.

I think it would be a pretty clean migration from attrs to plain dataclasses. We don't have much structural validation implemented at the moment, so it should be straightforward to start using pydantic's dataclass support for that. But migrating cattrs to pydantic might be more of a chore since we have built some things around the cattrs.Converter.

This came up in recent discussions with @mjreno in the context of an MF6 NetCDF specification and related tooling.

[mwtoews]

I recall pydantic as a difficult dependency a few years ago, as it required tight version pinning making it difficult to align with other packages in a unified environment. Perhaps things have settled down now with pydantic V2.

[wpbonelli]

Thanks for the warning @mwtoews we will have a look at that. Do you see any other reason to prefer one or the other? Originally I liked how attrs was a more powerful dataclasses and nothing else. Felt lightweight and focused. It isn't a big deal to write our own schema generation in python json schema directly but pydantic just makes it easy. However it does seem to have a lot more bells and whistles.

[wpbonelli]

Another benefit of pydantic is that validation can happen after attributes are set on the instance, which avoids some sticky situations we are presently faced with in load-time dimension resolution due to the way attrs does initialization/conversion/validation