-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Jinja2 2.9.4 - {% set %} and {% include %} don't work in the same template. #659
Comments
I cannot reproduce this at all in Jinja2. Added this regression test in 3e9937c but it passes. |
There must be more to this story. I'm going to close this bug however I will monitor the mentioned issue over here: ansible/ansible#20063 |
I have the same bug.
The problem with owl_count. It always equals 1. |
This looks a lot like something that could be done much cleaner with the |
Variables cannot be set in loops and that is intentional. It was never documented that you can override variables from higher scopes and that was considered a bug. See also #641 |
Maybe it'd be worth raising an exception when trying to do this in a way that worked in 2.8 but breaks in 2.9 to make it very clear that something is going wrong (except for weird behavior one might not notice immediately)? |
This patch fixes the bug with backwards-incompatible change in Jinja2 >= 2.9.4 which breaks use of the 'import' keyword in loops. More details: pallets/jinja#659 In this case, the 'normalize.css' file cannot be directly included in the 'index.html' welcome page, therefore it will be copied alongside it instead.
Expected Behavior
When a template contains:
And the include.j2 template contains anything, for example:
The original template should render:
Actual Behavior
In 2.8 this works normally.
In 2.9.3 & 2.9.4 the template doesn't render at all and drops an error:
However, it will render with the
{% set %}
line templated when no{% include %}
line exists, e.g.:Or with the
{% include %}
line without the{% set %}
line, e.g.:Template Code
Actual Run
I'm using Ansible 2.2.0 (I'll file a bug with Ansible too as I know this may not be considered a Jinja2 bug) - it's easily repeatable with the ad-hoc ansible command though:
Here is a more "complete" run to show the failure and success (in 2.8). Additionally, it shows that it will render properly with either just the {% set %} line, or just the {% include %} line - but not both.
https://gist.github.com/andymcc/2ddf98b50fa07e3f8b8648a440499fb8
I've added to a bug in Ansible, that already exists and seems related: ansible/ansible#20063
Your Environment
The text was updated successfully, but these errors were encountered: