Why do trim_blocks and lstrip_blocks under Flask/OpenShift produce different results when tested online, compared when to tested locally?
<p>I'm writing a simple web app using Flask, which is hosted on OpenShift. I want to control whitespace in my template files, with the Jinja command lines essentially removed as in:</p>

<pre><code>&lt;div&gt;
{% if True %}
    yay
{% endif %}
&lt;/div&gt;
</code></pre>

<p>...producing:</p>

<pre><code>&lt;div&gt;
    yay
&lt;/div&gt;
</code></pre>

<p>The Jinja docs at <a href="http://jinja2.readthedocs.io/en/latest/templates.html#whitespace-control" rel="nofollow noreferrer">http://jinja2.readthedocs.io/en/latest/templates.html#whitespace-control</a> (and other sources) imply I should do </p>

<pre><code>flask_app_obj.jinja_env.lstrip_blocks = True
flask_app_obj.jinja_env.trim_blocks = True
</code></pre>

<p>...which I have done, in my <strong>init</strong>.py file for my app package. However, this yields inconsistent behaviour when I test locally and then on OpenShift; locally, I get the expected result (i.e. the Jinja commands essentially removed, as if they were never there), and on OpenShift I get:</p>

<pre><code>&lt;div&gt;
        YAY
    &lt;/div&gt;
</code></pre>

<p>Consulting the docs and researching similar whitespace issues, it seemed there could be two causes of the inconsistency. Either there is something strange going on with newlines, with my local machine using a different scheme compared to the hosted OpenShift environment (along the lines of <a href="https://superuser.com/questions/374028/how-are-n-and-r-handled-differently-on-linux-and-windows">https://superuser.com/questions/374028/how-are-n-and-r-handled-differently-on-linux-and-windows</a>) and this produces different whitespace-culling behaviour when the template is generated at the OpenShift end, or, I am changing the Jinja2 environment object when it is shared or after a template has been loaded, which violates the docs which quote:</p>

<blockquote>
  <p>Instances of this class may be modified if they are not shared and if no template was loaded so far. Modifications on environments after the first  template was loaded will lead to surprising effects and undefined behaviour.</p>
</blockquote>

<p>... along the lines of <a href="https://stackoverflow.com/questions/23186691/stripping-whitespace-in-jinja2-flask-why-do-i-still-need-the-minus-sign">Stripping whitespace in jinja2 &amp; flask...why do I still need the minus sign?</a> and <a href="https://stackoverflow.com/questions/35956589/trimming-blocks-using-whitespace-control-from-jinja2-template">Trimming blocks using whitespace control from jinja2 template</a>. </p>

<p>Plausible causes, but I am in doubt they are the reason for the strange OpenShift-side template behaviour. If I had operated on the Jinja environment too early, surely I would see incorrect template output locally as well (which I don't, I get the expected result locally). Indeed, it's in my <strong>init</strong>.py file that I set lstrip_blocks and trim_blocks to True. I doubt it's a newline issue too since I am developing on OS X, and the OpenShift environment is *nix, so both environments should be using the same newline scheme.</p>

<p>Given the above, I have no more theories as to why I could be getting the inconsistent results between OpenShift testing and local testing. So my questions are these: Have I set the Jinja options in the wrong place and they should be somewhere other than <strong>init</strong>.py? Am I modifying the Jinja2 Environment inappropriately? Is my method of setting Jinja2 options just plain wrong? Perhaps I should be using some other avenue to set such options other than </p>

<pre><code>flask_app_obj.jinja_env.lstrip_blocks = True
flask_app_obj.jinja_env.trim_blocks = True
</code></pre>

<p>Thanks for answering.</p>