New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand templates during compilation #7
Comments
One thing that makes this more complicated is deciding precisely when to expand templates. If we do it after parsing happens, then the YAML/JSON parsers will encounter syntax errors. If we do it before parsing, on the other hand, we don't yet have type information about the stack's properties; as such, the context object's parameters will be weakly typed during the template's execution (a Catch-22, kinda sorta. More thinking required ... |
After noodling on this more, I wonder whether templates are the right solution. The more I dig into the design/implementation, the more C++ deja vu I get, complete with all the problems known to afflict the preprocessor. (Clang's modules doc lays out many of them.) The challenge is that it's less obvious how JSON/YAML could be used in a more "module-like" way without devolving into template substitution, and without us basically reinventing our own templating system. |
For YAML, it's possible some combination of anchors ( |
This change performs template expansion both for root stack documents in addition to the transitive closure of dependencies. There are many ongoing design and implementation questions about how this should actually work; please see #7 for a discussion of them.
Another thought on this. If we think about the metadata, there are actually two discrete sections:
As we consider the DSL extensions (#22), we would still consider 1 to be metadata (in a And this is the key insight. Perhaps templating should only be allowed within the service blueprint section ( |
This change adds a super simple initial whack at a basic cluster topology comprised of VPC, subnet, internet gateway, attachments, and route tables. This is actually written in Mu itself, and I am committing this early, since there are quite a few features required before we can actually make progress getting this up and running.
We've decided to move away from templating and instead use a real language approach. Therefore, this work item is obsolete. Closing. |
At the moment, we don't expand templates during compilation. We need to.
The intent is to use Go text templates, because it has all of the expressiveness we want out of a templating language. (Conditionals, custom functions, etc.) An alternative is to use something like Jsonnet, however (a) it is probably less familiar to the population at large, and (b) we want something that is file format agnostic.
As part of this, we need to decide what goes into the "context" object available to templates.
The text was updated successfully, but these errors were encountered: