gistfile1.txt

As I have started to apply saltstack to more complex, real world use cases, I am starting to encounter what I believe is some important shortcomings to jinja and alternative renderers. I would like to solicit feedback from the community on this issue. Perhaps there is a way to do this and I am just missing it.

I want to be able to drop blocks of inline python code in SLS files while still using the default renderer that everyone in the community uses, is in all the saltstack formulas, and is presented prominently in official saltstack documentation. I can currently do one or the other but not both. In other words, I can opt for a non-standard renderer such as mako or pydsl OR use jinja. I obviously cannot use python code within jinja templates. 

And please please don't mention custom jinja filters. [ shudders]

From a functionality perspective, I desperately need the ability to drop in blocks of python code in my SLS. Jinja simply does not cut it for any reasonably complex use case. In the real world, complex SLS configuration files (apache virtual hosts anyone?) requires programming logic that jinja just won't do or it will do but it would be significantly more painful to do. I don't want to be faced with a situation where i can either write 50 lines of jinja template or use an alt render and do it in three lines of python code.

However, from a community/ecosystem perspective, this puts me in a bind. Everyone uses jinja, that's what the formulas are in, that's what everyone is taught to use, and that's the default. So I would be faced with maintaining two lines of code: the alt renderer SLS that no one else will really understand or user and loose the ability to leverage formulas AND deal with the traditional jinja SLS in a separate branch. 

I think the choice of jinja as the default renderer was probably not the best considering its inability to handle inline python code. However, that's water under the bridge. At this point, I'd like to propose the following feature enhancements for SLS:
Explicit shebangs everywhere (so not to rely on the implicit default) 
Documentation that makes it clear *early on* that jinja is by no means the only (or a sensible choice). Also explicitly identify the jinja's limitation with inline python code and point to the other renders as alt.
Make Mako a first class citizen in the salt documentation. In other words, for every jinja example have the same example for mako. Since mako does support inline python code blocks AND its pretty similar to jinja AND saltstack already supports it, the only reason people are using jinja over mako is because of the documentation and formula examples. If we can get mako front and center, that might help push people to using a default renderer without this severe limitation.