add enumerated types

[gilesknap]

This allows us to add enumerated types as follows:

defs:
  - name: AllObject
    description: |
      Example object that has one of each arg type

      - type: enum
        name: my_int_enum
        description: integer enumerated type
        default: 2
        values:
          all_ahead: 1
          full_speed: 2
          ramming_speed: 3
          stop: 0

      - type: enum
        name: my_mixed_enum
        description: integer enumerated type
        values:
          first: hello
          second: world
          third: 3.0

and then use them like this in and IOC YAML:

ioc_name: test-multiple-ioc
description: a basic example for testing multiple support definitions
generic_ioc_image: ghcr.io/epics-containers/ioc-template:23.3.2

entities:
  - type: object_module.RefObject
    name: Ref1

  - type: module.AllObject
    name: A Consumer
    my_object: Ref1
    my_int_enum: 3
    my_mixed_enum: world

JSON schema will validate the type as well as values for those enums containing only one type.

The use of DICT gives each value a name that can give context to a developer who is reading the SUPPORT YAML but those names are not exposed when editing the IOC YAML.
THEREFORE: we could instead just have a list of values.

[gilesknap]

@coretl @GDYendell interested in your comments on this

particularly should the enums be listed via a DICT or LIST? The former allows us to name the values for context - but is only useful when looking in the support YAML file.

[coretl]

I vote list, with values that are strings. I think inventing names for the enum keys will take us too far back in builder directions...

[gilesknap]

@coretl
re types: The schema works really nicely with interpreting the types itself. So if I make a dict of

[gilesknap]

OK I have made it so that

• the names you use in the SUPPORT enum declarations are the names you use in the IOC yaml
• the values are rendered in Jinja
• blank values mean use the name for a value

e.g.

      - type: enum
        name: clock_rate
        description: |
          demonstrates use of VME clock rates as an enum
          this is an example of an 'illegal' python enum
        values:
          1Hz: 0
          2Hz: 1
          5Hz: 2
          10Hz: 3
          dummy:

supplying 1Hz in IOC YAML will render the arg as 0
supplying dummy will render the arg as dummy

only options allowed in schema for clock_rate are [1Hz, 2Hz, 5Hz, 10Hz, dummy]

[codecov-commenter]

Codecov Report

Merging #92 (69da8ff) into main (969e88e) will increase coverage by 0.42%.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##             main      #92      +/-   ##
==========================================
+ Coverage   96.22%   96.64%   +0.42%     
==========================================
  Files           9        9              
  Lines         371      388      +17     
==========================================
+ Hits          357      375      +18     
+ Misses         14       13       -1     

Files Changed	Coverage Δ
src/ibek/ioc.py	96.59% <100.00%> (+0.43%)	⬆️
src/ibek/support.py	97.70% <100.00%> (+0.20%)	⬆️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[gilesknap]

@coretl @GDYendell we are going to end up with repetition here.

Every support module that needs to supply clock rate to VME would need this enum described.

Is that an issue?

-- edit --

its worse than that. Every Entity that needs clock_rate would re-describe the enum.