Support ChainableUndefined for jinja2 Environment

Jinja 2.11 supports setting undefined option on an Environment to ChainableUndefined. This allows the default filter to work on nested elements and attributes.

Arguably this could be a better default behavior for use in copier, but regardless of the default it would be nice to be able to configure this in copier.yml. The _envops configuration exists, but there’s no way to set undefined to a python class in that YAML file (that I know of at least), so I think either a specific config value would be needed, or someway to lookup a class for the undefined key. I’m not sure which is the best or preferred way, but would like to turn this on to make the templates that use nested configuration easier to set their defaults.

[ppg]

Yes, sorry I should have included one.

This doesn’t have great support in copier (which is a different issue request), but if you have more complex configuration, say in .copier-answers.yml you have:

go:
  lint:
    changes_only: true

So that you can control when you generate a helper bash file to lint golang files whether to fail on any lint issues, or only ones that were introduced by a line your PR touches (i.e. a reviewdog pattern if anyone is interested). In my helper file to lint I want to do something like:

{%- if go.lint.changes_only|default(False) %}
golint ./...
{%- else %}
golint ./... | reviewdog -fail-on-error -f=golint -diff='git diff origin/master'
{%- endif%}

I would like that to also work for:

go: {}

or even no go key. If you can set the jinja2’s Environment’s undefined is set to ChainableUndefined it will, but with how copier has it you must do:

{%- if go and go.lint and go.lint.changes_only|default(False) %}
golint ./...
{%- else %}
golint ./... | reviewdog -fail-on-error -f=golint -diff='git diff origin/master'
{%- endif%}

[yajo]

I read the linked comment, but I don’t think that’s how it works is it? At least not on v5.1.0. I routinely change .copier-answers.yml and run copier --force update and it reads the answers and then applies them.

Believe me, I’m the maintainer, I know how this thing works. 😋

I merged recently #317 to clarify this misunderstanding. The fact it works for you is an accident because you didn’t happen to hit any corner cases yet (or because you hit them but didn’t notice), but yes, that’s an unsupported way of updating, and it will always be because of technical reasons explained there.

If you have further questions regarding this subject, please open a new discussion. Let’s keep the issue focused, I hope you don’t mind. 😄