Assume poor communication between Cherwell admins and users of this package. Be able to handle unexpected schema changes, within reason.
(N.B. This design principle is not a reflection of my personal experience with Cherwell admins.)
To deal with schema changes, autogenerate Pydantic models from Business Objects and maintain them in a separate git repository. Ensure that schema changes result in understandable diffs.
If we have API access to both the staging and production Cherwell instances, take advantage of this (schema changes will probably appear in staging and then move to production).
Prefer code generation if it offers advantages such as:
- Subclassing classes with mypy/pylance type checking in IDE
- Faster startup - this package might be used for short-lived scripts that are called often
- Developer understanding
Generated code should be as human readable as possible. It should be stable enough to be version controlled such that CVS changes make sense to the observer.
Must be able to connect to multiple Cherwell instances at the same time. Use cases: comparing test and production schemas, transferring / comparing business objects between instances.
Async first development because my use case requires it. A sync overlay could be considered.
Make full use of Pydantic's features and approach.
- Type hinting for a better IDE experience
- Discoverability
- ipython helpers (repr, autocomplete)