Add jinja2 extensions

[jayvdb]

Especially helpful is statement support, aka do

http://jinja.pocoo.org/docs/2.10/extensions/#expression-statement

Loop Controls would also be nice syntax to have available.

https://github.com/duelafn/python-jinja2-apci looks very helpful for debugging, and for intentionally breaking templates when backwards compatibility is not possible.

https://github.com/wewearglasses/jinja2-required-variables-extension looks great for performance improvements.

https://github.com/zehome/jinja2-commentif looks good for adding comments without the hash prefix which is a keyword in jinja2

https://github.com/tlatsas/jinja2-highlight would be great for documentation.

While very basic, it would also by good to add https://pypi.org/project/jinja2-git/ , and add new git based information to that extension.

Likewise https://pypi.org/project/jinja2-github/ and https://github.com/hackebrot/jinja2-time

https://github.com/stanfeldman/compressinja looks interesting.

https://github.com/danielchatfield/jinja2_markdown or https://github.com/nrsimha/jingo-markdown might be better as an optional moban extension.

https://github.com/jpscaletti/jinja-includewith is a nice syntax improvement

Note to self: see if https://github.com/mankyd/jinjatag is still usable.

[jayvdb]

Perhaps we need some way to enable jinja extensions in the moban yaml. That way people can choose which ones they need.

But enabling expression-statement and loop-controls by default seems sensible. Extra features for free.

[jayvdb]

https://pypi.org/project/jinja2-pimport/ exposes all of python to the templates.

https://pypi.org/project/jinja2-python-version/

https://pypi.org/project/Jinja2-template-info/

https://pypi.org/project/jinja2-stringcase/

https://pypi.org/project/jinja2-slug/

https://github.com/sadimusi/jinja2compact

https://github.com/audreyr/jinja2_pluralize

https://pypi.org/project/jinja2modern/

https://github.com/raicheff/jinja2-minify

https://pypi.org/project/jinja2_maps/

https://pypi.org/project/jinja2time/

https://github.com/Lispython/jinja-kit/blob/master/jinja_kit/utils.py - html sanitizer

https://github.com/frascoweb/jinja-macro-tags - better syntax for macro calls

https://github.com/frascoweb/jinja-macro-tags

https://pypi.org/project/typogrify/ or https://github.com/raicheff/jinja2-typogrify helper

https://github.com/mbr/jinja-vanish

[jayvdb]

thanethomson/statik#6 shows jinja extensions being configurably added by a tool with a similar ethos.

[ayan-b]

I was trying to solve the issue. The user adds the required extensions in the yaml or mobanfile, something like:

extensions:
  - jinja2.ext.do
  - jinja2.ext.loopcontrols

And I am passing the list of extensions through BaseEngine, i.e.,
BaseEngine(template_dirs, context_dirs, engine_cls, extensions). But this clearly breaks all the tests which use BaseEngine and thus all of them need to be updated. As can be found from the docs, the extensions need to be passed while declaring the environment. So, I am thinking of passing extensions without breaking BaseEngine.

[chfw]

I am going to enable this extensions syntax.

extensions:
  jinja2:
    - jinja2.ext.do
    - jinja2.ext.loopcontrols
  handlebar:
    - xxx.x..x..
  template_type:
    - ....

[chfw]

@ayan-b can you help contribute some docs for extensions? for it to go out, as my personal convention, it needs some thing like this: docs/level-12-specify-engine-extensions. This doc should be readable and testable. In tests/test_docs.py, there exists all docs test commands.

My extensions work lives in extensions branch

[ayan-b]

@ayan-b can you help contribute some docs for extensions? for it to go out, as my personal convention, it needs some thing like this: docs/level-12-specify-engine-extensions. This doc should be readable and testable. In tests/test_docs.py, there exists all docs test commands.

My extensions work lives in extensions branch

Sure. However, as per #90 (comment) , we should have expression-statement and loopcontrol enabled by default. I can make a PR doing the same. What do you think?

[jayvdb]

Note https://build.opensuse.org/package/show/devel:languages:python/python-jinja2-time already exists, also https://apps.fedoraproject.org/packages/python-jinja2-time and https://packages.debian.org/stretch/python-jinja2-time

fedora has more at https://apps.fedoraproject.org/packages/s/Jinja

[jayvdb]

Can we have some docs showing / testing use with jinja2-time and https://github.com/duelafn/python-jinja2-apci

[ayan-b]

@chfw as it turns out the corresponding package needs to be imported, for example, if we want to use jinja2_time needs to be imported.

from jinja2 import Environment
import jinja2_time

env = Environment(extensions=['jinja2_time.TimeExtension'])

env.datetime_format = '%a, %d %b %Y %H:%M:%S'

# Timezone 'utc', default format -> "Thu, 10 Dec 2015 15:49:01"
template = env.from_string("{% now 'utc' %}")

template.render()

env.datetime_format = '%a, %d %b %Y %H:%M:%S'--> this part will be solved by #202 .

[ayan-b]

I am solving #202 first and will make a PR related to this once #202 is merged.

[jayvdb]

I think jinja extensions could be part of the 'options' mapping.

[ayan-b]

I think jinja extensions could be part of the 'options' mapping.

I also thought the same but that would be somewhat inefficient as per the current moban architecture since the extensions are always required to be included during environment initialization. So, in that case, the environment is needed to be initialized for each template --> output process.

[chfw]

Any more change for this issue? Since we have already added extensions support.

[ayan-b]

Any more change for this issue? Since we have already added extensions support.

We need to dynamically import the extension, for example import jinja2_time.

[chfw]

Dynamic import could be achieved easily.

[chfw]

why jinja2_time should be imported whereas jinja2.ext.loop shall not? Is there a natural rule that we can code it up?

[ayan-b]

why jinja2_time should be imported whereas jinja2.ext.loop shall not? Is there a natural rule that we can code it up?

Yup, for example, the extensions are: jinja2_time.TimeExtension and jinja2.ext.do, then we need to import jinja2_time and jinja2. Since, jinja2 is already imported, we need not to import it once again.

I am sending a PR related to this.

[chfw]

since 0.6.2, moban -e jinja2=your_custom_jinja2_extension will load your custom jinja2 extension as well

[chfw]

practical usage of -e: https://github.com/chfw/math-sheets/blob/master/reception/a_op_b_op_c/make.sh

[chfw]

Here is the documentation on its usage inside mobanfile: https://moban.readthedocs.io/en/latest/level-12-use-template-engine-extensions/README.html

[chfw]

since 0.8.2, the extended syntax below, will activate ad-hoc filter, test and global of your choice.

moban -e jinja2=filter:moban.externals.file_system.url_join \
         jinja2=test:moban.externals.file_system.exists \
         jinja2=global:description=moban.constants.PROGRAM_DESCRIPTION \
      -t "{{ 'a'|url_join('b')}} {{'b' is exists}} {{description}}`