Added enum support to Measurement Client

[MounikaBattu17]

• This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Added enum support for Measurement Client
Implements Task 2827579: Extend support to enums.

Why should this Pull Request be merged?

With this implementation, Measurement Client supports measurements with enum parameters.

• Created a new enum class using enum values from metadata annotations.
• The new enum class name in created using parameter name suffixed with Enum in pascal case. Also, removed special characters from the class name.
  For example,

  parameter name = Enum In
  enum class name = EnumInEnum     # PascalCase(parameter name) + "Enum"

• Stored the created enum class in enum_values_by_type_name which acts as a map to eliminate repeating enums.
  For example, Configuration Enum In and Output Enum Out will use the same Enum class, so enum_values_by_type_name will be useful to avoid creating duplicate enums for both parameters.
• Applied enum_type while creating pools for the metadata.
• While black formatting the rendered template, replaced this enum class pattern.
  enum_type=<enum 'EnumInEnum'>) -> enum_type= EnumInEnum

What testing has been done?

Added automated tests.
Generated and verified the client with enum params like enums, enum arrays, and sparse enums.

[github-actions]

Test Results

    30 files  ±0      30 suites  ±0   38m 42s ⏱️ - 8m 11s
   651 tests ±0     651 ✅ ±0      0 💤 ±0  0 ❌ ±0 
16 130 runs  ±0  15 060 ✅ ±0  1 070 💤 ±0  0 ❌ ±0 

Results for commit 31a11e9. ± Comparison against base commit 0462410.

♻️ This comment has been updated with latest results.

[MounikaBattu17]

We construct new enum class using enum values from metadata.annotations. Unlike enums, LabVIEW rings, doesn't pass ring values in metadata.annotations. Thus for rings, we have treated them as integers. So this is the behaviour for enums and rings

enum parameter in measurement:

enum parameter in python client:
u32_animal_enum_in: U32AnimalEnumInEnum = U32AnimalEnumInEnum.Gopher

ring parameter in measurement:

ring parameter in python client:
u32_color_ring_in: int = 1

So, ring values can be only be set to integers in client, we cannot use the name (RED, GREEN, BLUE) here.

Please share your thoughts on this

@bkeryan We confirmed this behaviour for LabVIEW client. Can you please share your thoughts on this behaviour for python client.

[MounikaBattu17]

There is a mypy error and will be fixed soon.

[MounikaBattu17]

There is a mypy error and will be fixed soon.

Fixed.

The error was on this line
new_enum_type = Enum(new_enum_type_name, enum_values) # error: Enum() expects a string literal as the first argument [misc]

seems like mypy static analysis checks for a string literal but we pass a variable.

To resolve this error, I've used enum __call__ method directly to create enums dynamically at runtime.
new_enum_type = Enum.__call__(new_enum_type_name, enum_values)

[bkeryan]

There is a mypy error and will be fixed soon.

Fixed.

The error was on this line new_enum_type = Enum(new_enum_type_name, enum_values) # error: Enum() expects a string literal as the first argument [misc]

seems like mypy static analysis checks for a string literal but we pass a variable.

To resolve this error, I've used enum __call__ method directly to create enums dynamically at runtime. new_enum_type = Enum.__call__(new_enum_type_name, enum_values)

This is an indication that we are using the enum functional API wrong (as far as the Mypy authors are concerned, at least).

I don't think that calling dunder methods directly is a good solution, because dunder methods are typically implementations of Python features that have their own syntax, and in most cases you should use that syntax instead.

If we absolutely must use the enum functional API in this way, then I would prefer to use # type: ignore[misc] on the line that does this and put a comment above it saying why we have to do it this way.

Also I don't think the generated code should be doing this at all. It has static definitions of all of the enum types and it should use them.

[MounikaBattu17]

If we absolutely must use the enum functional API in this way, then I would prefer to use # type: ignore[misc] on the line that does this and put a comment above it saying why we have to do it this way.

Seems like MyPy static analysis throws an error if we don't use a direct string literal for dynamic Enum creation. So I have suppressed the error instead of using dunner method like you suggested.

Syntax like,

Enum('Color', {"NONE":0, "RED": 1}) -> no mypy error

enum_name: str = "Color"
Enum(enum_name, {"NONE":0, "RED": 1}) -> throws mypy error

Also I don't think the generated code should be doing this at all. It has static definitions of all of the enum types and it should use them.

Removed and used the already available metadata.

[jayaseelan-james]

Should this method go into _support.py?

[jayaseelan-james]

Prefer f-strings for better readability.

[jayaseelan-james]

It might be an over-ask but because we showcase "protobuf enums" in our sample measurement, should we also test the Protobuf Enum type with our client to ensure we're not missing anything on that part?