Old Notes

1. APIs for load_config_dir, load_variable_dir, load_schema_dir, load_template_dir
2. Can be JSON, YAML data
3. jinja templates (allow config of jinja?) maybe make jinja out of band
4. load all configs -> load all variables -> load all schemas -> load all templates -> resolve variables in configs -> enforce schemas -> generate final artifacts with templates

Some kind of data pipelining system

What orchestrates actually building stuff? Is that a separate config?

All tests are "integration", elaborate and complex test data

Serve SVG use case first, then HTML

Do we also allow configuring generic tasks and post-processing steps?

Find the boundary between config and code

addressed resolve variables every config-load, don't resolve variables monolithically at the end

addressed dict loader won't work, have to read from file

addressed compile: put data (options for output format) into a build/cache dir with some name. Consumes configs, schemas, variables (all optional, besides configs)

addressed render: provide template dirs, relative path to template, path to monolithic config file