Jinjia import path - Githubissues

alessandrothea commented 3 years ago

Hi,

I'm am playing around with templates, trying to get the hang of making new ones, and stumbled upon the following issue: I would like to re-use the jinjia cpp macros provided by moo (ocpp.hpp.j2) but I found no way to tell moo/jinjia to look for them in moo/templates/ocpp.hpp.j2 if the template is not the one provided by moo.

For instance

moo -T effective_robot/schema/effective_robot/templates -g /lang:ocpp.jsonnet -A path=dunedaq.dfmodules.hdf5datastore -A ctxpath=dunedaq -A os=dfmodules/HDF5DataStore.jsonnet render -o dfmodules/hdf5datastore/Nljs.hpp omodel.jsonnet Nljs.hpp.j2

fails because jinjia at

{% import 'ocpp.hpp.j2' as cppm %}

with the message

Traceback (most recent call last):
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/bin/moo", line 11, in <module>
    load_entry_point('moo==0.5.2', 'console_scripts', 'moo')()
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/moo/__main__.py", line 350, in main
    cli(obj=None)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/moo/__main__.py", line 287, in render
    text = ctx.obj.render(templ, data)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/moo/__main__.py", line 83, in render
    return moo.templates.render(templ, dict(model=model, moo=helper))
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/moo/templates/jinjaint.py", line 46, in render
    return tmpl.render(**params)
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "/home/ale/devel/dbt-tests/mk01/build/effective_robot/schema/effective_robot/templates/Nljs.hpp.j2", line 1, in top-level template code
    {% import 'ocpp.hpp.j2' as cppm %}
  File "/home/ale/devel/dbt-tests/mk04/dbt-pyvenv/lib/python3.8/site-packages/jinja2/loaders.py", line 197, in get_source
    raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: ocpp.hpp.j2
ninja: build stopped: subcommand failed.

I was assuming that jinjia would look for it in moo/templates/ocpp.hpp.j2 but it doesn't seem the casa. Not it seems to take into account the template path(s) passed as CLI arguments. I've made a few tests copying ocpp.hpp.j2 and Nljs.hpp.j2 to different directories and adding both to the path, but no joy.

I wonder if I'm doing something wrong or it's a limitation on Jinjia's side. Any advice?

brettviren commented 3 years ago

I wonder if I'm doing something wrong or it's a limitation on Jinjia's side.

No, not you. What you are expecting matches what "should" be happening.

Jinja is blameless as it checks paths as given by the app.

moo "should" append to the default moo/templates/ path any given by -T flags. This appending may be "bad" because it means one can not override any template file provided in the default path - but that's a different story maybe for a different issue.

So, something is broken. I'll add a test for this and then a fix.

brettviren commented 3 years ago

It was indeed some brokenness in getting the path into Jinja properly. Paths were generally a mess and are now cleaned up.

For easy CLI checking see the moo path and moo resolve commands. Examples added:

https://brettviren.github.io/moo/buildsys.html#paths https://brettviren.github.io/moo/buildsys.html#resolve

brettviren / moo

Jinjia import path #18