epics-containers / ibek

IOC Builder for EPICS and Kubernetes
https://epics-containers.github.io/ibek
Apache License 2.0
10 stars 4 forks source link

Add pre_values and Jinja strict mode #223

Closed gilesknap closed 1 month ago

gilesknap commented 1 month ago

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:

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 https://github.com/epics-containers/ibek/blob/b414a3cb389715da3460f9b0c540b11f45829c0e/tests/samples/support/technosoft.ibek.support.yaml#L202-L206 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 commented 1 month ago

@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:

Any ideas?

gilesknap commented 1 month ago

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 commented 1 month ago

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

https://github.com/epics-containers/ibek/blob/b414a3cb389715da3460f9b0c540b11f45829c0e/tests/samples/support/technosoft.ibek.support.yaml#L202-L206

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 commented 1 month ago

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

gilesknap commented 1 month ago

@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 commented 1 month ago

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

gilesknap commented 1 month ago

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

GDYendell commented 1 month ago

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.