A command line tool for rendering pongo2 (jinja2) templates to stdout.

The rendering library is pongo2.

It is inspired (and pretty much a copy of) the j2cli utility for Python, but leveraging Golang's static compilation for easier use in Docker and other minimal environments.

p2 defaults to using the local environment variables as a data source.

If --format is specified explicitely, then p2 will read that format from stdin (or the supplied given data file specified with --input).

If only --input is specified, then it will guess the data type based on the file extension.

Render template with environment variables (most useful for Docker):

p2 -t template.j2

Render a template with environment variables piped from stdin:

cat vars.env | p2 -t template.j2

Render a template with using a JSON source file:

p2 -t template.j2 -i source.json

Render a template using a YAML on stdin:

cat someYaml | p2 -t template.j2 -f yaml

p2 allows enabling a suite of non-standard pongo2 filters which have side-effects on the system. These filters add a certain amount of minimal scripting ability to p2, namely by allowing a single template to use filters which can perform operations like writing files and creating directories.

These are unsafe filters to use with uninspected templates, and so by default are disabled. They can be enabled on a per-filter basis with the --enable-filters flag. For template debugging purposes, they can also be enabled in no-op mode with --enable-noops which will allow all filters but disable their side-effects.

It is technically possible to store complex data in environment variables. p2 supports this use-case (without commenting if it's a good idea). To use it, pass the name of the environment variable as the --input and specify --use-env-key and --format

p2 -t template.j2 -f json --use-env-key -i MY_ENV_VAR

p2 implements the custom write_file filter extension to pongo2. write_file takes a filename as an argument (which can itself be a templated value) and creates and outputs any input content to that filename (overwriting the destination file).

This makes it possible to write a template which acts more like a script, and generates multiple output values. Example:

input.yml:

users:
- user:
  name: Mike
  content: This is Mike's content.
- user:
  name: Sally
  content: This is Sally's content.
- user:
  name: Greg
  content: This is Greg's content.

template.p2:

{% macro user_content(content) %}
{{content|safe}}
{% endmacro %}

{% for user in users %}
##  {{user.name}}.txt output
{% set filename = user.name|stringformat:"%s.txt" %}
{{ user_content( user.content ) | write_file:filename }}
##
{% endfor %}

Now executing the template:

$ p2 -t template.p2 -i input.yml --enable-filters write_file



##  mike.txt output


This is Mike's content.

##

##  sally.txt output


This is Sally's content.

##

##  greg.txt output


This is greg's content.

##

$ ls
greg.txt  input.yml  mike.txt  sally.txt  template.p2

We get the output, but we have also created a new set of files containing the content from our macro.

Note that until pongo2 supports multiple filter arguments, the file output plugin creates files with the maximum possible umask of the user.

It is recommended to build using the included Makefile. This correctly sets up Go to build a cgo-independent, statically linked binary.

Note: users on platforms other then Linux will need to specify GOOS when building.

Vendoring is managed by govendor