Relative paths when including templates?

[ivanfetch]

I was using the kolypto / j2cli tool, but am looking to switch to yours. It doesn't appear that it's possible to use relative paths when including templates?

$ jinja2 management.json.j2 x.yaml
Traceback (most recent call last):
  File "/usr/bin/jinja2", line 11, in <module>
    sys.exit(main())
  File "/usr/lib/python2.6/site-packages/jinja2cli/cli.py", line 335, in main
    sys.exit(cli(opts, args))
  File "/usr/lib/python2.6/site-packages/jinja2cli/cli.py", line 257, in cli
    output = render(template_path, data, extensions, opts.strict)
  File "/usr/lib/python2.6/site-packages/jinja2cli/cli.py", line 183, in render
    output = env.get_template(os.path.basename(template_path)).render(data)
  File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/home/pr-ifetch/jinja/management/management.json.j2", line 6, in top-level template code
    {% include "../common/parameters.json.j2" %}
  File "/usr/lib64/python2.6/site-packages/jinja2/loaders.py", line 168, in get_source
    pieces = split_template_path(template)
  File "/usr/lib64/python2.6/site-packages/jinja2/loaders.py", line 31, in split_template_path
    raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: ../common/parameters.json.j2

[mattrobenolt]

My guess, without digging into it, is because it's poking outside of the template loader directory: https://github.com/mattrobenolt/jinja2-cli/blob/master/jinja2cli/cli.py#L172

Off hand, do you know how this can be worked around? I can expose this as a CLI argument to add additional directories here, but not entirely sure if this can easily just be done for "allow anything".

[mattrobenolt]

We can either just expand the search path to effectively match root, or we can just do a custom Loader that works based on relative from where it's being executed without restriction.

[ivanfetch]

@mattrobenolt I don't know which of those options is best, but if a custom loader extends some existing loader code and then allows relative loading from the directory containing the Jinja2 template, that sounds like the best option. I don't really know what I'm talking about RE: Python though.

I am starting to compare your code and the kolypto / j2cli fork, to see why the j2cli tool does work with relative include paths.

[mattrobenolt]

No worries, I haven't looked at that care, but it doesn't particularly matter. My code is explicitly disallowing it because in most normal uses of Jinja, this is correct/secure behavior. Say, in use of a web server. You don't want things poking into different directories outside of what you define. But in our case, it's a CLI tool and we explicitly are invoking behaviors that we want, not from user input.

I'll probably just hack together a quick custom loader that allows this behavior. Thanks for bringing it up!

[ivanfetch]

I understand now RE: explicit behavior in Jinja, protecting what can be loaded. Thanks for looking into this, I appreciate your time @mattrobenolt.

[Bagnall]

I would also find this useful for including common jinja macros to several jinja templates.

[giftig]

Is there a workaround for this? I've just hit a wall because I can't include templates; I'm using this as part of a build and can't hardcode an absolute path into the template.

HA: actually, yes I can, since I'm actually running jinja2-cli in a docker container.

It doesn't seem to be working for me with absolute paths either

[giftig]

We can either just expand the search path to effectively match root

Ah, okay, I've just noticed this. so I guess I can only load from directories which are below the root template. I'll try that.

Okay, that works. Good enough as a workaround 👍

[netchild]

Hi,

I'm looking into a templating engine to replace my old/outdated/unmaintained one to generete static weg pages. What I had in the old is a directory with templated/includes, and the content directory. And then a make job to generate html pages from the content. I had now a look into jinja2-cli and it seems I've hit this issue (with absolute path instead of relative path).

I'm using jinja2-cli as of v0.7.0.

As an example:

• folders ./htdocs_jinja and ./jinja-includes
• in ./jinja-includes I have the file jina_page.html which is using "include" for some other files inside jinja-includes
• in ./htdocs_jinja I have my content index.jinja, and some variables in index.env
• when I cd into ./htdocs_jinja and run "jinja2 --format=env index.jinja index.env -o index.html" I get:

File "/usr/local/lib/python3.7/site-packages/jinja2/_compat.py", line 37, in reraise raise value.with_traceback(tb) File "/www/www.leidinger.net/htdocs_jinja/index.jinja", line 1, in top-level template code {% extends "%s/%s" % (template_base, 'jinja_page.html') %} File "/usr/local/lib/python3.7/site-packages/jinja2/loaders.py", line 187, in get_source raise TemplateNotFound(template) jinja2.exceptions.TemplateNotFound: /www/www.leidinger.net/jinja_templates/jinja_page.html

First line of index.jinja is:
{% extends "%s/%s" % (template_base, 'jinja_page.html') %}

And the content of index.env is:
template_base=/www/www.leidinger.net/jinja_includes

The goal in the end is to have 3 directories, the template/include stuff, the content, and the output. The output can then be rsynced to a webserver, without transferring the input/templates too. It also facilitates the cleanup (delete all files in the output directory without worrying about deleting the input/template files).

Is this possible with jinja2-cli in the near future? If I read this bugreport it looks like this is not really a priority.

Bye,
Alexander.

[netchild]

I've just seen pull request #76, which seems related to this. Any chance this will go in soon and a new release with this?