Rather than relying on basic template strings, move to supporting external templates. The logical choice for these templates is Jinja2 for many reasons, but primarily because it is full-featured and well known (limit friction to new users).
The end goal is to support user-provided templates for third-party extensibility of this tool.
The third-party developer experience should be that they create:
1) A directory containing the template file(s) that their schematic should render. Suggest that these have a filename pattern .template.
2) A schema.json file containing metadata for the params that should be adjustable from the CLI, including type information and/or help
3) Support for unparameterized templates and static files in schematics. Suggest that these have a special filename pattern such as .static.. This is so that files such as unparameterized Jinja2 templates can be copied as part of the schematic creation without having a nightmarish nesting of templates-that-render-templates
The end-user experience should essentially be that they pip install third_party_template_library and then immediately has access to flaskerize generate third_party_template_library:cool_doodad --with=some_option`.
A number of useful formatting functions for tasks like converting between camel/pascal/kebob/snake case etc should be provided.
We can support user-provided template functions by hooking into a specifically named module/function-return and updating the global jinja env context.
Rather than relying on basic template strings, move to supporting external templates. The logical choice for these templates is Jinja2 for many reasons, but primarily because it is full-featured and well known (limit friction to new users).
The end goal is to support user-provided templates for third-party extensibility of this tool.
The third-party developer experience should be that they create: 1) A directory containing the template file(s) that their schematic should render. Suggest that these have a filename pattern.template.
2) A schema.json file containing metadata for the params that should be adjustable from the CLI, including type information and/or help
3) Support for unparameterized templates and static files in schematics. Suggest that these have a special filename pattern such as .static.. This is so that files such as unparameterized Jinja2 templates can be copied as part of the schematic creation without having a nightmarish nesting of templates-that-render-templates
The end-user experience should essentially be that they
pip install third_party_template_libraryand then immediately has access to flaskerize generate third_party_template_library:cool_doodad --with=some_option`.A number of useful formatting functions for tasks like converting between camel/pascal/kebob/snake case etc should be provided.
We can support user-provided template functions by hooking into a specifically named module/function-return and updating the global jinja env context.