how to handle jinja2 clashes with django template language

[ccurvey]

I've seen some hints (e.g. {% raw %} / {% endraw %} and putting a _copy_without_render in my cookiecutter.json file...but they seem unsatisfying.

I'd like to do something like this:

{% extends "{{cookiecutter.project_name}}/authenticated_base.html" %}

But my "extends" (which is supposed to be the Django Template Language - DTL) conflicts with Jinja2's "extends"

on a related note:

<a href="{% url '{{cookiecutter.project_name}}:person-update' person.uuid %}">Update</a>

seems to blow up because Jinja2 doesn't have a {% url %} tag.

Is there a pattern here that I'm missing?

[ccurvey]

I think I may have found a solution (or at least a decent hack). I have some post-processing shell scripts that I use to do things like install software into my environment, create databases, etc.

1. Add this to cookiecutter.json

    "_copy_without_render": [
        "website/{{cookiecutter.project_name}}/templates/*.html"
    ]

This tells cookiecutter to just copy the templates without editing them.

2. Add this to my post-processing script

find {{cookiecutter.project_name}}/templates -type f -exec sed -i 's/{% raw %}{{cookiecutter.project_name}}{% endraw %}/{{cookiecutter.project_name}}/g' {} +

then I can write my templates "normally" (without {% raw %} like so

{% extends "{{cookiecutter.project_name}}/base.html" %}

and just let find + sed take care of the substitution in my template directory.

[ccurvey]

There may be better solutions! (But I have not tried them yet.)

Apparently you can override the markers that identify Jinja blocks and variables. This post suggests that you can put a special header in your files that looks like this:

#jinja2:variable_start_string:'<<' , variable_end_string:'>>', block_start_string:'<%', block_end_string:'%>'

which will allow you to use different characters to mark Jinja "stuff" -- that might avoid having the Jinja preprocessor clash with the Django Template Language processor.

If you do a web search for "jinja variable_start_string", it appears there is a way to set this in the Jinja environment, but I don't have the first clue about how to do that.

[ccurvey]

I'm not having much luck with this. It seems that jinja2 is not respecting block_start_string and block_end_string directives, which means that my DTL {% for ... is causing confusion. I'm going back to my sed solution for the time being.