-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Labels
enhancementNew feature or requestNew feature or request
Description
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:
- 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)
- PROs
- Develop our own code generator
- PROs
- Can write it to suite only our needs
- No baggage
- CONs
- High effort
- PROs
- 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)
- PROs
Originally posted by @CalebCourier in #20 (comment)
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request