Summary
Although bindings are generated, currently the Python package that uses the bindings is hand crafted e.g. __init__.py files that import each compiled extension and define TemplateClassDict convenience aliases (#13). This can cause drifts from the config e.g. stale/missing aliases when classes or template instantiations change, and orphaned files left behind when a module is removed.
It would be useful to add an opt-in feature to generate the Python package from the same config so it can't drift:
- One Python subpackage for each config module.
- Generate only config-related content that can easily drift (import list of all wrapped classes, add
TemplateClassDict aliases etc.) but don't overwrite bespoke parts of the package that are intended for manual maintenance.
- Ensure cross-module imports are done correctly in the Python package.
Summary
Although bindings are generated, currently the Python package that uses the bindings is hand crafted e.g.
__init__.pyfiles that import each compiled extension and defineTemplateClassDictconvenience aliases (#13). This can cause drifts from the config e.g. stale/missing aliases when classes or template instantiations change, and orphaned files left behind when a module is removed.It would be useful to add an opt-in feature to generate the Python package from the same config so it can't drift:
TemplateClassDictaliases etc.) but don't overwrite bespoke parts of the package that are intended for manual maintenance.