While my motive is to generalize validation for the purposes of supporting toml configuration (#873), I think this change stands on its own merits:
Simpler testing -- we no longer need to build Configparser's or specify prefixes.
Eliminate ServiceConfigMetaclass. While IMO an elegant solution, it's unnecessarily complex when only one of our services (azuredevops) has a prefix that varies from the service name, which can be treated as the only allowed exception going forward.
Reduce reliance on our custom pydantic ValidationError. This class is difficult to follow since it is mostly engaged with pydantic's data model and not ours. Furthermore, it appears that it will likely have to be completely redone to support pydantic-2. (On an optimistic note, I expect the implementation to be simpler because pydantic-2 will implement some of the features I've hacked onto it and they appear to be changing their data model to simplify customization.)
Pulled out of #973 / #983.
While my motive is to generalize validation for the purposes of supporting toml configuration (#873), I think this change stands on its own merits:
ServiceConfigMetaclass. While IMO an elegant solution, it's unnecessarily complex when only one of our services (azuredevops) has a prefix that varies from the service name, which can be treated as the only allowed exception going forward.ValidationError. This class is difficult to follow since it is mostly engaged with pydantic's data model and not ours. Furthermore, it appears that it will likely have to be completely redone to support pydantic-2. (On an optimistic note, I expect the implementation to be simpler because pydantic-2 will implement some of the features I've hacked onto it and they appear to be changing their data model to simplify customization.)