After I struggled some time to get the ini parser to work, I realised there is no possibility to use dotenv format, that is, ini files without sections, or exactly the output of env bash command.

This would actually allow something like env |jinja2 helloworld.tmpl --format=ini, that brings environment support more close to j2cli project.

I had to dig in closed github issues to find out about environ() trick (which is undocumented also) and I personally find hacky, since it requires special jinja templates, not sharable with ansible for example.

Thank you for your time!

Right now, we optimistically import every dependency, json, yaml, toml, etc, even if they're not being used.

These should be loaded on-demand only when needed to make execution time faster.

Hey @mattrobenolt! I'm using your project in all of mine, thank you very much for it 🙂

I'd like to propose a feature: being able to specify the template with an URL. jinja2-cli would retrieve it itself to render it with the given data.

Use-case:

• I have lots of projects that I generate from a template (currently based on cookiecutter, soon transitioning to copier).
• Each one of these generated projects therefore has the same Python scripts that generate JSON data, and their corresponding Jinja templates (I'm auto-generating a CREDITS.md file, sometimes the README.md as well, and CHANGELOG.md but it's a bit more complex and I use git-changelog for this).
• I'd like to avoid this redundancy. For the Python scripts generating data, I can make Python packages of them, published on PyPI. But for templates, packages would be overkill. I think it would be super user-friendly to be able to use templates directly from a GitHub repository for example. It would allow users to customize templates very easily (just fork it or copy it in one of your repo, change it as you like).

In fact, adding this feature would allow me to write many small Python packages depending on jinja2-cli to auto-generate things. They would just act as a wrapper around jinja2-cli, providing the data themselves and calling jinja2-cli with user's argument. Users being able to use their own online templates would make for the best experience! Neither them or I would need to duplicate these templates everywhere.

Now for the implementation:

• templates consisting of one file: easy. Just pass its URL to jinja2-cli
• templates consisting of several files: less easy. Should jinja2-cli clone the repository? How would it initialize the Jinja env, the Jinja loader? How to tell which file is the template entry-point?

Anyway, before thinking more about this, I'd like to know what you think of this feature 🙂

I noted i can't use the enviroment variable in my template [commit: 4b6c048]. I made some testing with this template:
[export TEST=succes]
{% if environ.TEST is defined %}TEST={{ environ.TEST }}{% endif %}

I pin-poin the issue at this line:
env.globals['environ'] = os.environ.get
I'm not an expert with jinja2, but i think you need to pass a dictionary (I noticed an iterable is fine) and not a fuction.
I fixed by changing the line with:
env.globals['environ'] = dict(os.environ)
or (becouse os.environ is iterable)
env.globals['environ'] = os.environ

I think the functionality need to be documented in the README.

Hello,

Thank you for putting this handy tool together! Today I noticed that some of my blocks are displaying even though my environment variables are not defined.

My environment:

Output of jinja2 --version:

jinja2-cli v0.6.0
 - Jinja2 v2.10

Here is my test.j2:

With is defined set:

{% if environ('DEFINED_VARIABLE') is defined %}
This should display.
{% endif %}

{% if environ('NOT_DEFINED_ABCD1234') is defined %}
This should NOT display.
{% endif %}

I even attempted to follow this #31 (comment) and set it to is none:

{% if environ('DEFINED_VARIABLE') is defined %}
This should display.
{% endif %}

{% if environ('NOT_DEFINED_ABCD1234') is none %}
This should NOT display.
{% endif %}

Command I am executing:

export DEFINED_VARIABLE=Hello
jinja2 test.j2 > test.txt

Expected results of test.txt:

This should display.

Actual results of test.txt:

This should display.

This should NOT display.

Any thoughts would be appreciated!

Hello 🙂 ! Do you plan to make a new release soon?

Currently I'm stuck because I need #72, and installing from git, master branch in GitLab CI gives me this: python-poetry/poetry#853.

Hi,

Since jinja2-cli got some new functionalities since the last release, can we have a new one? It would also be easier for me to use it on my projects.

assume a json file:

{
  "foo": "bar"  // some random comment
}

This should be allowed as a data source for populating template

Please deploy a new version to pypi.

echo "hello {{ toto }}, I'm {{ titi }}" > input.file
jinja2 --strict -D "titi=test" -o output.file input.file

then jinja2cli issues exception which is the expected behavior, but instead of leaving the output file as it is, it's already scratched to zero

will it be possible to only flush the output file if the jinja2cli succeeded.

this will be a bonus, replacing the content of file:

echo "hello {{ toto }}, I'm {{ titi }}" > same.file
jinja2 --strict -D "titi=test" -o same.file same.file

could the input file and the output file be the same file as sed -i option allows to replace within the same file

the behavior is that the file is scratched to zero and there is no exception triggered.

the input file could be read, processed then if everything is fine flushed back into the same file to be closed.

my aim is to replace into all my scripts the sed -i by jinja2cli

Thanks a lot already for this smart package

Hey,
Sorry to bug you again, but the last release of this package has been at the beginning of this year and there were few issues closed since then, could you make a release to pypi? That would allow us to package your application, rather than our fork

Of course, this could be done in CI manner with Travis or something else in order not to require your time.

keep_trailing_newline is True by default with jinja2-cli, which is not the prescribed default configuration of Jinja2 (http://jinja.pocoo.org/docs/2.9/templates/#whitespace-control). There doesn't appear to be a way to alter this behavior short of modifying the code?

The issue at hand is that this makes one particular scenario a huge challenge: conditionals with whitespace sensitive output. For example,

Keep the blank below this line.

{% if variable1 %}
    Variable1 is true.
{% elif variable2 %}
    Variable2 is true.
{% endif %}

Keep the blank above this line.

Without any "-" for whitespace control, you get added newlines. If you add a trailing "-" to the statement jinja will eat all the whitespace, newline and spaces. If you add a leading "-" to the statement then jinja will eat all the leading whitespace and newlines. All options ruin whitespace formatting and you're forced to putting the Jinja2 templates inline--making reading the source material more challenging.

Running the below gives me an error about passing the strict option. I've tried including it both before the template name and after the input file but get an error in either case.

jinja2 service.j2 api_gateway.yml --format=yml --strict
Usage: jinja2 [options] <input template> <input data>

jinja2: error: no such option: --strict

The main reason I use j2cli at the moment is for it's support of environment variables, but it doesn't support Python 3 and no one seems to be maintaining it.

Would a patch to add environment support be considered?

Hi

I would like to use these filter https://github.com/Midnighter/jinja2-ospath in jinja2-cli
I tried to use --extension but i got the error : ImportError: No module named extension.pyc

Do you know how i can do it ?

Regards

Hi

Nice project BTW...

I suggest to add an option in the command line to ignore/bypass when there is a undefined variable on the template and do nothing with it, (by default the variable is replaced with null/empty)

I think this will be helpful when you have multiple variable inputs for the same template, so I can execute things like.

jinja2 --ignore_unknown my_template.j2 input1.yaml | jinja2 --ignore_unknown my_template.j2 input2.yaml | jinja2 my_template.j2 input3.yaml

Regards

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

ansible has huge set of filters which will be nice if we can import filters from it.

Hi,

When rendering a template with missing attributes, I get no warning or return code indicating the issue.

j2 warns the user with jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'some_mising_attribute'

I'm using the following versions:

j2 --version
j2cli 0.3.1-0, Jinja2 2.8

jinja2 --version
jinja2-cli v0.5.0
 - Jinja2 v2.8

I think the issue is in the call to the rendermethod, but I could not spot any difference with the way j2 calls the render.

Tell me if you need help to investigate this.

Thanks

Description

Tried to run a template with only one variable {{carrier} to produce a python file. This produced this stack trace.

(data_platform) alexlordthorsen@Alexs-MBP ~/git/data/data-platform/dags/dags/reconciliation/carrier_configs [1] :( % jinja2 config_template.jinja "fedex.py" -D carrier=fedex
Traceback (most recent call last):
  File "/Users/alexlordthorsen/.venvs/data_platform/bin/jinja2", line 8, in <module>
    sys.exit(main())
  File "/Users/alexlordthorsen/.venvs/data_platform/lib/python3.8/site-packages/jinja2cli/cli.py", line 424, in main
    sys.exit(cli(opts, args))
  File "/Users/alexlordthorsen/.venvs/data_platform/lib/python3.8/site-packages/jinja2cli/cli.py", line 257, in cli
    if has_format(ext):
  File "/Users/alexlordthorsen/.venvs/data_platform/lib/python3.8/site-packages/jinja2cli/cli.py", line 81, in has_format
    get_format(fmt)
  File "/Users/alexlordthorsen/.venvs/data_platform/lib/python3.8/site-packages/jinja2cli/cli.py", line 74, in get_format
    return formats[fmt]()
KeyError: 'py'

Versions

(data_platform) alexlordthorsen@Alexs-MBP ~/git/data/data-platform/dags/dags/reconciliation/carrier_configs :) % python --version
Python 3.8.2
(data_platform) alexlordthorsen@Alexs-MBP ~/git/data/data-platform/dags/dags/reconciliation/carrier_configs :) % pip list | grep jinja2-cli
jinja2-cli 0.7.0

The samples directory is a bit small.

For instance, it could use some shell scripts.
Even a hardcore shell scripter sometimes wants an example.

Hi,

I like the project and use it. I would like to take over the maintaining: Merge the pull requests, write some test, deploy a new version to pypi.

What do you think of this idea?

jinja-cli crashes unless the Jinja library dependency is version 2.11.0. Currently the package wants "any"

using Jinja2 version 2.10.3, you get

from jinja2 import ChainableUndefined
ImportError: cannot import name 'ChainableUndefined'

ChainableUndefined was added in Jinja2 v2.11.0

Hi @mattrobenolt,

Don't know if you have a docker image, but i integrated your cli into a image i created:
https://github.com/dinuta/jinja2docker

If you like it, please advertise it. It is used and tested in production.

I'm trying to debug a jinja2 template. The associated variables file passes yamllint, but jinja-cli claims that it is malformed. Any suggests as to how I can proceed?

user:~$ sudo -i bash -c 'umask 002 ; pip install --force-reinstall -U yamllint jinja2-cli'
Collecting yamllint
  Using cached https://files.pythonhosted.org/packages/87/ca/9866f1c49301efb1f9c3b03eb879a95611e71dd56f73d2d45d537a5e1518/yamllint-1.11.1-py2.py3-none-any.whl
Collecting jinja2-cli
  Using cached https://files.pythonhosted.org/packages/ca/0f/dd461ac244fec4310c425e9cec9553d8ae8523c36837792e7666c6e53393/jinja2_cli-0.6.0-py2.py3-none-any.whl
Collecting pathspec>=0.5.3 (from yamllint)
Collecting pyyaml (from yamllint)
Collecting jinja2 (from jinja2-cli)
  Using cached https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl
Collecting MarkupSafe>=0.23 (from jinja2->jinja2-cli)
Installing collected packages: pathspec, pyyaml, yamllint, MarkupSafe, jinja2, jinja2-cli
  Found existing installation: pathspec 0.5.7
    Uninstalling pathspec-0.5.7:
      Successfully uninstalled pathspec-0.5.7
  Found existing installation: PyYAML 3.13
    Uninstalling PyYAML-3.13:
      Successfully uninstalled PyYAML-3.13
  Found existing installation: yamllint 1.11.1
    Uninstalling yamllint-1.11.1:
      Successfully uninstalled yamllint-1.11.1
  Found existing installation: MarkupSafe 1.0
    Uninstalling MarkupSafe-1.0:
      Successfully uninstalled MarkupSafe-1.0
  Found existing installation: Jinja2 2.10
    Uninstalling Jinja2-2.10:
      Successfully uninstalled Jinja2-2.10
  Found existing installation: jinja2-cli 0.6.0
    Uninstalling jinja2-cli-0.6.0:
      Successfully uninstalled jinja2-cli-0.6.0
Successfully installed MarkupSafe-1.0 jinja2-2.10 jinja2-cli-0.6.0 pathspec-0.5.7 pyyaml-3.13 yamllint-1.11.1
user:~$ yamllint test.yml
user:~$ jinja2  --format=yml test.j2 test.yml
Traceback (most recent call last):
  File "/usr/local/bin/jinja2", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/jinja2cli/cli.py", line 335, in main
    sys.exit(cli(opts, args))
  File "/usr/local/lib/python2.7/dist-packages/jinja2cli/cli.py", line 234, in cli
    raise raise_exc(u'%s ...' % data[:60])
jinja2cli.cli.MalformedYAML: ---

wazuh_agent_configs:
  - .os: 'Linux'
    localfile:
   ...
user:~$

stdin don't seem to work. it just shows help.

echo "test" | jinja2

This is a bit of a weird one since it's a general python problem, but it also affects this tool.

$ echo "øl"
øl
$ echo "øl" > test
$ jinja2 test 
øl
$ jinja2 test > test2
Traceback (most recent call last):
  File "/bin/jinja2", line 11, in <module>
    load_entry_point('jinja2-cli==0.7.0', 'console_scripts', 'jinja2')()
  File "/usr/lib/python2.7/site-packages/jinja2cli/cli.py", line 364, in main
    sys.exit(cli(opts, args))
  File "/usr/lib/python2.7/site-packages/jinja2cli/cli.py", line 290, in cli
    sys.stdout.write(output)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in position 0: ordinal not in range(128)

and workaround this is

$ export PYTHONIOENCODING=utf-8
$ jinja2 test > test2
$ cat test2
øl

This is explored here https://stackoverflow.com/q/1473577/558194

So, to be a general Unix tool this should ideally support UTF-8, thus I would suggest implementing something to address potential issues.

Dear Matt:

moban dev team noticed your effort to bring jinja to command line interface. We are doing the same thing as you are doing. Would you like to check us out? https://moban.readthedocs.io/en/latest/

Thanks

I have this directory structure on current workdir:

.
└── service
    ├── base.yaml
    ├── external
    │   └── base.yaml
    └── internal
        └── base.yaml

The ./service/internal/base.yaml has a {% extends "./service/base.yaml" %} which works correctly if I run the jinja2 module manually with:

from jinja2 import Environment, FileSystemLoader, select_autoescape
env = Environment(loader=FileSystemLoader('.'))
env.get_template('service/internal/base.yaml').render()

But running jinja2 CLI fails:

$ jinja2 service/external/base.yaml
...
jinja2.exceptions.TemplateNotFound: service/base.yaml

I think jinja2 tool needs to use the current workdir ($CWD) as the search directory (or have a --flag to signal a /path/to/templates).

Currently, there is no way to force jinja2-cli to stop processing a template when an environment variable is missing. The template is rendered with None as the missing value. It would be awesome if jinja2-cli would fail on the missing variable.

I would like to write a travis configuration with test and coverage enabled. Also we could test with python 2 and python 3.

What do you think?

It might be useful to allow overrides, or just basic import os os.environ.

I'm not even sure this is the real cause, but here it is. I simplified the commands to keep it clear.

I want to run this:

$ ./output-json.py | jinja2 --format=json template.md

Easy right? But it leaves blanks were I put variables in my template. Indeed:

$ ./output-json.py | jinja2 --strict --format=json template.md
[truncated]
jinja2.exceptions.UndefinedError: 'main_usage' is undefined

I check that output-json.py actually outputs JSON:

$ ./output-json.py  # output truncated for readability
{"main_usage: "...", "commands": [...]}

So it seems jinja2-cli doesn't get my JSON contents.

But if I do

json_text="$(./output-json.py)"
echo "${json_text}" | jinja2 --format=json template.md

It works!!!! 😮

And

$ diff <(./output-json.py) <(echo "${json_text}")

...gives absolutely no difference!

Could it be because I'm running a Python script as input, and another Python script as output (jinja2), which messes with something in jinja2-cli's code? It seems crazy 😕

I tried variants like cat <(./output-json.py) | jinja2 ..., python output-json.py | jinja2 ..., echo "$(python output-json.py)" | jinja2 ..., but they all failed the same way.

I will try to get a reproducible example.

Maybe worth noting: I work with poetry in a virtualenv with Python 3.6. My jinja2-cli version is v0.6.0 and Jinja2 is v2.10.

Since today, I have an issue to use your great tool: I always get the following error, when I want to convert a template to HTML:

Traceback (most recent call last):
  File "/usr/local/bin/jinja2", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/jinja2cli/cli.py", line 335, in main
    sys.exit(cli(opts, args))
  File "/usr/local/lib/python2.7/dist-packages/jinja2cli/cli.py", line 261, in cli
    sys.stdout.write(output)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 436: ordinal not in range(128)

What could be the reason for this error? I haven't changed anything in the template.

what am I doing wrong here?

pip install jinja2-cli

yields no binary but your instructions say I can just run it as directly. The module only installs .py and .pyc files...

Hi,

I use this tool often in a Windows environment (Git Bash to be specific) and would like to start using the feature where you can load the context/data on STDIN. This seems to work fine on Linux, but on Windows [8.1 Pro] returns this error:

(Note: this is using the files from the sample/ directory in the project's repo)

#
# Passing the template and context as arguments on the command line works:
#
$ jinja2 sample.jinja2 sample.json
<html>

<ul>
    <li>foo</li>
    <li>bar</li>
    <li>baz</li>
    </ul>

</html>
#
# Trying to load the context from STDIN returns an error:
#
$ cat sample.json | jinja2 sample.jinja2
Traceback (most recent call last):
  File "c:\python27\Lib\runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python27\Lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Users\Mike\.virtualenvs\myproject\Scripts\jinja2.exe\__main__.py", line 9, in <module>
  File "c:\users\mike\.virtualenvs\myproject\lib\site-packages\jinja2cli\cli.py", line 335, in main
    sys.exit(cli(opts, args))
  File "c:\users\mike\.virtualenvs\myproject\lib\site-packages\jinja2cli\cli.py", line 195, in cli
    if is_fd_alive(sys.stdin):
  File "c:\users\mike\.virtualenvs\myproject\lib\site-packages\jinja2cli\cli.py", line 189, in is_fd_alive
    return bool(select.select([fd], [], [], 0)[0])
select.error: (10038, 'An operation was attempted on something that is not a socket')

In many cases you'll have templates with just one or two variables. It's quite a hassle to create a data file each time.

Heya!
Since redirecting the output of a command relies on the used shell, it would be quite helpful to have a parameter that tells the program where to write the rendered template to.

I know it is overkill, but we've been using Ansible only to render Jinja2 templates only because we need a few custom filters and I didn't find a way to do it using any command line tool.

If one wants to use only environment variables then the second argument is not useful, hence it would be nice to make it optional.

Workaround:

$ echo '{}' | jinja2 example.tpl -

Related to #25

I've searched through the code but it doesn't seem to allow output to STDOUT independent of input. Can we add this feature? The use case would be to pass param via -D but render to jinja2 template of config without having to generate a file.

Would be nice to be able to use the ansible ipaddr filter in jinja2-cli.

I think it would be useful to take a look at how variable precedence is being evaluated.

The current hierarchy seems to be: template > cli param > input file
I would suggest instead: cli param > input file > template

The suggested order would give more priority to specifically defined variables and less priority to more generally defined (template-level) vars.

should be able to

echo 'test' | jinja2

Request

Currently it seems like -D parameter names are treated as a single value. It would be useful if the parameter used dot notation to parse it and allow it to be accessed the same way that the yaml parameters are.

See below for an example.

Example

test.tmpl

{
  foo: {{house.bathroom.size}}
  bar: {{house.kitchen.size}}
}

params.yaml

house:
  bathroom:
    size: 20

CLI Command

$ jinja2 test.tmpl params.yaml -D house.kitchen.value=55

Error Received

Traceback (most recent call last):
  File "/Users/nlofaso/.virtualenvs/platform-cdk/bin/jinja2", line 10, in <module>
    sys.exit(main())
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2cli/cli.py", line 424, in main
    sys.exit(cli(opts, args))
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2cli/cli.py", line 314, in cli
    out.write(render(template_path, data, extensions, opts.strict))
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2cli/cli.py", line 229, in render
    return env.get_template(os.path.basename(template_path)).render(data)
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2/asyncsupport.py", line 76, in render
    return original_render(self, *args, **kwargs)
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "/Users/nlofaso/tmp/test.tmpl", line 3, in top-level template code
    bar: {{house.kitchen.size}}
  File "/Users/nlofaso/.virtualenvs/platform-cdk/lib/python3.7/site-packages/jinja2/environment.py", line 430, in getattr
    return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'kitchen'

Somewhat related to #37 and #55 I want to give jinja2-cli ability to search other directories for {% include 'othertemplate.j2' %} that exists in another directory outside of the root path for the current template.

The suggestion for doing this is adding commandline option -I/--include to indicate which directories should be searched for templates.

Is is possible to add support for sourcing environment variables, like the old j2 tool was doing?

Right now I have to modify my code to force it to use environment variables, which was not the case with the j2 tool.

TypeError: load() missing 1 required positional argument: 'Loader'

Traceback (most recent call last):
  File "/home/ubuntu/.tox/unit/bin/jinja2", line 11, in <module>
    sys.exit(main())
  File "/home/ubuntu/.tox/unit/lib/python3.6/site-packages/jinja2cli/cli.py", line 424, in main
    sys.exit(cli(opts, args))
  File "/home/ubuntu/.tox/unit/lib/python3.6/site-packages/jinja2cli/cli.py", line 279, in cli
    data = fn(data) or {}
TypeError: load() missing 1 required positional argument: 'Loader'

A solution may be to use yaml.safe_load instead (e.g. on line 135 of cli.py):

    return yaml.safe_load, yaml.YAMLError, MalformedYAML

Else the Loader argument will need to be provided.

Hi,
I noticed that doing pip install j2cli[yaml] and pip3 install j2cli[yaml] installs v0.3.1.
How can we get it updated to 0.5+?
Thx