Skip to content

Note for Future Improvement #21

@CalebCourier

Description

@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)

Originally posted by @CalebCourier in #20 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions