Skip to content
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 introduces change with free variables in loops that breaks Lektor #649

freakboy3742 opened this issue Jan 9, 2017 · 3 comments


Copy link

freakboy3742 commented Jan 9, 2017

Using Lektor 2.3; If you have a project with a sitemap (using the template suggested by the Lektor docs):

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="">
  {%- for page in [site.root] if page != this recursive %}
  <url><loc>{{ page|url(external=true) }}</loc></url>
  {{- loop(page.children) }}
  {%- endfor %}

and you have jinja2 2.9 - 2.9.3, in your environment, you get a build error:

(lektor) rkm$ lektor build
Started build
U ar_AR/sitemap.xml
E ar_AR/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U sitemap.xml
E sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U pt_BR/sitemap.xml
E pt_BR/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)
U zh_TW/sitemap.xml
E zh_TW/sitemap.xml (NameError: free variable 'l_1_this' referenced before assignment in enclosing scope)

Downgrading to Jinja2 2.8.1 seems to resolve the problem.

Reporting there because it would seem to be a regression in Jinja2; however, it's also been reported as lektor/lektor#343 in case it's a usage error.

Copy link

Indeed this is a scoping bug that regressed.

Note to self: this is caused by the filter expression being scoped to the same scope. This needs to be changed to be an independent scope.

Copy link

Second note to self: the old and new compilation for loop filters is unsound. It compiles to two different modes depending on the extended loop flag but which on the generated code side produces different scoping rules. In extended loops a new frame is needed according to the generated code, in non extended looping the scope can be reused.

However if the latter compilation mode is actually valid is unclear and needs to be investigated.

Copy link

At least fixing those bugs is easy now but man those regressions suck. Needs better test coverage :(

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
None yet

No branches or pull requests

2 participants