V0.5.0 Final Cut

[CalebCourier]

Final adjustments and fixes based on guardrails-ai/interfaces#6 and the ser/de work on the open source.

Depends On

guardrails-ai/interfaces#6

TODO

• Merge V0.5.0 Final Cut interfaces#6
• Release 0.3.6 0.3.8
• Test
• If Stable, release 0.4.0 to have a stable minor base. Could also bump to 0.5.0 if we want to match with the open source.

[CalebCourier]

Note for Future Improvement

As you can see from these changes, it has become abundantly clear that the code generation tool chain for python is inadequate. Most of the issues are the result of the library trying to do too much (ser/de, using restrictive pydantic types, etc.), but in some cases the generator is just buggy (i.e. not including all properties in ser/de methods). If we want to limit the number of customizations we have to apply to the generated code in the future, I believe we have a few options:

1. Contribute to the existing python generator
   • PROs
     • Continue to use the same library
     • Contribute back to the community
   • CONs
     • Difficult to find source code (activation energy)
     • Have to deal with legacy code (backwards compatibility)
2. Develop our own code generator
   • PROs
     • Can write it to suite only our needs
     • No baggage
   • CONs
     • High effort
3. Write the API client manually and use pydantic generated OpenAPI Spec to generate other language clients
   • PROs
     • Python native, less chance of churn in open source
     • No baggage in Python classes
     • Can support both http and gRPC
     • Can use current auto-generated classes as a base (less activation energy)
   • CONs
     • Will likely still need hot-fix scripts bc pydantic uses some undesirable patterns when producing OpenAPI Spec (i.e. anyOf type + null instead of just using required array)
     • Limited to OpenAPI Spec instead of full JSON Schema
     • Will have to write endpoint methods ourselves (not complex, just toilsome)