changing Jinja2's delimiters from Ansible, or within Jinja2?

[Nick]

Hi,

I'm attempting to use Ansible to install Exim configs using the template module, which is problematic since Exim uses both dollars and curly braces as part of its config syntax.

The only workaround I've found is to wrap things in the {% raw %} ... {% endraw %} tags, which is clumsy.  From reading around it sounds like it is possible to change the delimiter but only at the Python API level.

Assuming I need to template the configs, is there some way of stopping Jinja2 from trying to expand {{ ... }} and ${ ... } in selected templates?

Thanks,

N

[Michael DeHaan]

I would not be opposed to a patch that sets something like this at the
very top line of the template

# delimiter={@ basic_replace=False

??

> --
>
>

[Nick]

On 11/11/12 14:42, Michael DeHaan wrote:
> I would not be opposed to a patch that sets something like this at the
> very top line of the template
>
> # delimiter={@ basic_replace=False
>
> ??
>

Sounds good, and I'd like to help out but unfortunately I'm not well
tooled to create such a patch, not having much Python hacking experience
so far. Pointers where to look would help to encourage me to try fixing
this.

Cheers,

N

[Brian Coca]

In the templates module, when initializing the jinja2 environment you can pass optional start/stop delimiters:

environment = jinja2.Environment(loader=loader, trim_blocks=True,block_start_string='@@',block_end_string='@@',variable_start_string='@=', variable_end_string='=@')

would change {% statement %} to @@ statement @@

and {{ var }} into @= var =@.

Make it a config option and only pass if set, otherwise jinja will use it's own defaults.

--

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

[Michael DeHaan]

the trick about making it a config option would make it that way for
ALL templates, so I was proposing we have some way to include that
info commented out at the top of the template, almost like a shebang
interpeter line

> --
>
>

[Brian Coca]

yes, making it a template module parameter does seem like a smaller change.

[Michael DeHaan]

yeah, but not as a module parameter you'd have to put in the playbook,
but something you'd just put at the top of the template.

that way the choice can travel with the template itself

> --
>
>

[Brian Coca]

I was trying to avoid either opening the file before calling jinja2 or forcing jinja2 to reevaluate it's own environment and reprocess the current template, but it does give you the most 'flexible' interface for the person writing the template.

It should not be too hard to write, just need some time.