Feature request: add support for jinja2 Environment options

[Kamilcuk]

Hi, it would be absolutely amazing to add the following options:

--trim_blocks
--lstrip_blocks

They would translate 1:1 to jinja2.Environment options.

Thanks!

[mattrobenolt]

I'm thinking maybe something a bit more generic for setting any of these:

https://github.com/mattrobenolt/jinja2-cli/blob/main/jinja2cli/cli.py#L264-L268

There's quite a lot of options here: https://jinja.palletsprojects.com/en/3.0.x/api/#jinja2.Environment

And I think if we're going to get into configuring them, it might make sense to just allow you to set any of them more as key=value pairs.

So something like:

--env trim_blocks=True --env block_start_string={{

Or something and this can cover all bases.

Thoughts?

[Kamilcuk]

Thoughts?

Hi. I would go with --trim_blocks --lstrip_blocks --block_start_string={{ options because it is simple and readable and easy and understandable and maintainable.

For --env trim_blocks=True --env block_start_string={{ you would have to write a custom conversion function that properly handles types - str, bool, int - depending on the option. This is work and is a maintenance burden, and the options will have to be enumerated anyway to get the type, and user error messages might be confusing --env invalidoption

[awmacpherson]

Reviving this issue as I'm interested in using jinja2-cli to render LaTeX templates, for which the default choices of delimiters are not very suitable.

For ease of maintenance and invocation, I'd like to suggest adding an argument --j2env-file that takes the path to a JSON file with jinja2 Environment parameters which are then passed to the constructor. Most of the currently defined options for Environment are of types that can be represented in JSON, and we can simply not support specifying the others (undefined, finalize, loader, bytecode_cache) on the CLI. The maintenance burden should be low because it becomes the responsibility of the user to ensure their j2env.json has keys recognised by jinja2.

If the maintainer thinks this seems like a reasonable approach and the feature has a good chance of being merged, I can make the PR myself.

[ddribin]

This would be a great addition! I would vote for two options: --trim-blocks and --lstrip-blocks. I would also vote for dashes throughout, instead of a mix of dashes and underscores, as that follows more typical Unix option names.