Caller can not be passed recursively to a call block inside a macro
joeUser555 opened this issue · comments
Issue
It is not possible to pass a caller to a call block inside a macro.
See attached file for an example.
What I did
I defined a macro which uses a caller and calls itself(recursive) using a call block and passes its own caller to the call block.
It seem to be impossible because the following exception occures:
Traceback (most recent call last):
File ".../jinja2cli.py", line 291, in <module>
main(scriptfile)
File ".../py/jinja2cli.py", line 283, in main
output = render_template(_fc, infilename, outfilename, 'node', config)
File ".../py/jinja2cli.py", line 249, in render_template
_output = _loader.load(_env)
File ".../py/jinja2cli.py", line 83, in load
_result = _template.render(**content)
File ".../venv/lib/python3.10/site-packages/jinja2/environment.py", line 1301, in render
self.environment.handle_exception()
File ".../venv/lib/python3.10/site-packages/jinja2/environment.py", line 936, in handle_exception
raise rewrite_traceback_stack(source=source)
File ".../jinja/test/test.jinja", line 33, in top-level template code
{% call(_k, _v) macro1(data.keys()) %}
File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
rv = self._func(*arguments)
File ".../jinja/test/test.jinja", line 18, in template
{% call(_k, _v) macro1(_k) %}
File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
rv = self._func(*arguments)
File ".../jinja/test/test.jinja", line 14, in template
{{ caller(voc, None) }}
File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
rv = self._func(*arguments)
File ".../jinja/test/test.jinja", line 19, in template
{{ caller(_k, _v) }}
File ".../venv/lib/python3.10/site-packages/jinja2/utils.py", line 83, in from_obj
if hasattr(obj, "jinja_pass_arg"):
jinja2.exceptions.UndefinedError: No caller defined
How to reproduce
Run the attached example file with jinja_cli or simmilar.
What I expected
I expected the caller is executed recursive inside the macro.
Conclusion
May be this is not a Bug Report but a Feature Request
Environment:
- Python version: 3.10
- Jinja version: 3.1.2
test.jinja.txt
Please include reproducing code in the description rather than as an attachment.
@davidism
The attachment gives more convenience for testing.
The code does not give more information that is not included in the description.
I see no reason for the required redundancy.
Why this issue is closed without a result ?
Probably because you decided to go for a (slightly) snarky response instead of including the code in the issue as expected?
Being able to check the code directly in the issue makes it much easier for us to have a look. Nothing wrong with having it attached as well. But for a first check having it immediately visible is much better than having to download an attachment...
Also, "reproducing code" means not just the jinja template but also the Python code you used to render the template.
Oh, and ideally you also come up with a minimal example to reproduce the problem!
PS: Try {% set outer_caller = caller %} before the call block and then use that inside instead of caller.
@ThiefMaster
First thanx for the work around.
Probably davidism has a slightly wrong perception.
What I wrote was never meant snarky or can you tell me that is technically wrong what I wrote ?
Your explanation (code in issue text) sounds plausible I will remember it for the next time.
Perhaps you can teach him to be less emotionally fragile(psychologically/mentally sensitive)
and present an explanation instead as you did.
The code to render a jinja template is the "template.render()" call as it is visible in the stacktrace.
Can you explain to me what python code could cause this kind of error ?
My example file should be self contained and should work with every jinjacli tool
thus making it independent form the calling python code.
Please tell me if I am wrong and what I can improve next time.
Thank you for being so patient.
Yikes, you really know how to piss off people who VOLUNTEER their time maintaining open source software. Tip: basically calling maintainers insane is NOT a good way to get them to help you.
FYI my point was that maintainer time is valuable. If the issue has no immediately visible code, then it's less convenient for us. And thus less likely to get your question answered.
And the Python code? Again it's faster if there's code we can paste to reproduce your issue. Yes, again, we are lazy. Because humans are lazy. Make it easy for us to reproduce your issue. That implies something we can run "out of the box", and that's minimal (quite sure your example template isn't minimal).