Add pre_values and Jinja strict mode

[gilesknap]

This PR includes the final changes to make the technosoft motor example work well.

First we have added a new pre_values key to Definition. When fields of an Entity are being evaluated they are done in this order:

• pre_values
• args
• values

This allows us to generate values that can be used throughout the args and also values that can rely on all the args being already rendered. This is important when we are using Jinja rendering in these fields.

The example of the num value in

ibek/tests/samples/support/technosoft.ibek.support.yaml

Lines 202 to 206 in b414a3c

	pre_values:
	- name: num
	description: The auto incrementing axis number
	value: |-
	{{ __utils__.counter("motorTML.axisCount", start=0) }}

required pre_values because it is needed both in the CONFIG arg and also in the pre_init

This PR also introduces strict Jinja rendering that will fail if you use non-existent variables. With additional test to validate the feature.

[gilesknap]

@coretl @GDYendell it's naming time!

I said to Tom I did not want to change the name of 'values' but I've checked and this as yet undocumented feature is currently only used in the technosoft support yaml.

Therefore we have an opportunity to change the names:

• pre_values
• values
  To something more consistent.

Any ideas?

[gilesknap]

ALSO: I have this feeling that it would be real nice if ALL 'pre_values' were evaluated before ANY args.

With that feature I could then have the controller know how many axes got greated and not have to manually declare the axis count in the controller YAML.

[amichelotti]

This PR includes the final changes to make the technosoft motor example work well.

First we have added a new pre_values key to Definition. When fields of an Entity are being evaluated they are done in this order:

• pre_values
• args
• values

This allows us to generate values that can be used throughout the args and also values that can rely on all the args being already rendered. This is important when we are using Jinja rendering in these fields.

The example of the num value in

ibek/tests/samples/support/technosoft.ibek.support.yaml

Lines 202 to 206 in b414a3c

	pre_values:
	- name: num
	description: The auto incrementing axis number
	value: |-
	{{ __utils__.counter("motorTML.axisCount", start=0) }}

required pre_values because it is needed both in the CONFIG arg and also in the pre_init
This PR also introduces strict Jinja rendering that will fail if you use non-existent variables. With additional test to validate the feature.

Good job, it seems to me a clean way.

[gilesknap]

@amichelotti I have released this to PyPI as 3.0.0b4 so you can try in your generic IOC if you like.

[gilesknap]

@coretl @GDYendell it's naming time!

I said to Tom I did not want to change the name of 'values' but I've checked and this as yet undocumented feature is currently only used in the technosoft support yaml.

Therefore we have an opportunity to change the names:

• pre_values
• values
  To something more consistent.

Any ideas?

And it has occured to me that Args are not really arguments they are parameters. But I really don't want to change that.

[coretl]

How about pre_defines (done before making any Entities) and post_defines (done after making Entities but before rendering them)?

[gilesknap]

How about pre_defines (done before making any Entities) and post_defines (done after making Entities but before rendering them)?
Not bad!

[GDYendell]

And it has occured to me that Args are not really arguments they are parameters. But I really don't want to change that.

This is true. I believe the convention is parameters are the definitions and arguments are the actual values. But, given we don't use the term parameters (yet?) I don't think this is particularly confusing.