DAQmx code generator for error_codes.py and constants.py using scrapigen metadata

[vigkre]

• This PR creates DAQmx code generator to generate error_codes.py and constants.py.
• Added attributes.py and enums.py to the metadata. Currently the attribute.py and enums.py are created under PR's 119 and 127 in scrapigen
• This PR can be merged once the scrapigen metadata is merged such that both repos are synced.
• Added the mako templates necessary for generating error_codes.py and constants.py.
• The newly generated error_codes.py and constants.py replaces the files generated by native daqmx code generator (https://dev.azure.com/ni/DevCentral/_git/ni-central?path=/src/daqmx/api/nidaqmx_py/source/nidaqmx_codegen) which is currently residing in (https://github.com/ni/nidaqmx-python/tree/master/src/nidaqmx)

[zhindes]

I went through constants.py. My general guidelines

• I'm fine breaking compatibility here, but lets be consistent moving forward.
• I prefer spelling out names, eg ONBOARD not ONBRD
• I prefer not repeating the name of the enum in the value. So ActiveLevel.ABOVE is better than ActiveLevel.ABOVE_LEVEL
• I don't think we can lead with numbers, eg 1_VALUE, so we try to spell out numbers. I think for consistency we should do that everywhere.

Before we hack on the generator / metadata, lets make sure @bkeryan and I agree with our guidelines.

EDIT: Oh, and these breaking changes are going to break many existing tests. We can't change them in this PR since we're building nidaqmx out of source still, but we will need to update them at some point. Let's make sure we have that tracked in the Features/User Stories or something. I'll at least notice when we switch the pyproject.toml to be from generated. I'll want to ensure all tests pass then.

[zhindes]

There were no updates to generated/nidaqmx/error_codes.py like you indicated there should be. Did you miss something?

[bkeryan]

I went through constants.py. My general guidelines

• I'm fine breaking compatibility here, but lets be consistent moving forward.
• I prefer spelling out names, eg ONBOARD not ONBRD
• I prefer not repeating the name of the enum in the value. So ActiveLevel.ABOVE is better than ActiveLevel.ABOVE_LEVEL
• I don't think we can lead with numbers, eg 1_VALUE, so we try to spell out numbers. I think for consistency we should do that everywhere.

Before we hack on the generator / metadata, lets make sure @bkeryan and I agree with our guidelines.

EDIT: Oh, and these breaking changes are going to break many existing tests. We can't change them in this PR since we're building nidaqmx out of source still, but we will need to update them at some point. Let's make sure we have that tracked in the Features/User Stories or something. I'll at least notice when we switch the pyproject.toml to be from generated. I'll want to ensure all tests pass then.

I would be happy if we generated the same names as before, warts and all. I don't mind improving names that are bad, but there are so many differences and it's not as clear cut as with mangled attribute ids like ai_acceld_b_ref.

Remember, the goal is to generate nidaqmx-python and nidaqmx.proto with the same metadata, so we don't need a ton of substitutions and special cases to map Python names to gRPC names. The goal isn't to fix all of the weird naming inconsistencies in nidaqmx-python (though that would be nice).

[zhindes]

I would be happy if we generated the same names as before, warts and all. I don't mind improving names that are bad, but there are so many differences and it's not as clear cut as with mangled attribute ids like ai_acceld_b_ref.

Remember, the goal is to generate nidaqmx-python and nidaqmx.proto with the same metadata, so we don't need a ton of substitutions and special cases to map Python names to gRPC names. The goal isn't to fix all of the weird naming inconsistencies in nidaqmx-python (though that would be nice).

I hadn't considered your second point about consistency between Python and gRPC. I think that is a really important observation. So I think my guidelines are now this in order of priority.

1. Prefer not breaking compatibility, but I expect it will happen. It isn't a showstopper.
2. Prefer consistency with gRPC.
3. If something has to change or be incompatible with gRPC, then:
   • I prefer spelling out names, eg ONBOARD not ONBRD
   • I prefer not repeating the name of the enum in the value. So ActiveLevel.ABOVE is better than ActiveLevel.ABOVE_LEVEL
   • I don't think we can lead with numbers, eg 1_VALUE, so we try to spell out numbers. I think for consistency we should do that everywhere.

Not exactly black and white, but hopefully something like this can give some direction?

[bkeryan]

I would be happy if we generated the same names as before, warts and all. I don't mind improving names that are bad, but there are so many differences and it's not as clear cut as with mangled attribute ids like ai_acceld_b_ref.

Remember, the goal is to generate nidaqmx-python and nidaqmx.proto with the same metadata, so we don't need a ton of substitutions and special cases to map Python names to gRPC names. The goal isn't to fix all of the weird naming inconsistencies in nidaqmx-python (though that would be nice).

I hadn't considered your second point about consistency between Python and gRPC. I think that is a really important observation. So I think my guidelines are now this in order of priority.

1. Prefer not breaking compatibility, but I expect it will happen. It isn't a showstopper.

2. Prefer consistency with gRPC.

3. If something has to change or be incompatible with gRPC, then:

   • I prefer spelling out names, eg ONBOARD not ONBRD
   • I prefer not repeating the name of the enum in the value. So ActiveLevel.ABOVE is better than ActiveLevel.ABOVE_LEVEL
   • I don't think we can lead with numbers, eg 1_VALUE, so we try to spell out numbers. I think for consistency we should do that everywhere.

Not exactly black and white, but hopefully something like this can give some direction?

Ok, that seems reasonable to me.

[MounikaBattu17]

Please find the differences in generated constants.py Vs expected constants.py listed below:

1. Missing Enums -> These enums are not used in nidaqmx-python. Hence removed

Action
BreakMode
CalibrationTerminalConfig
EndCalAction
InputCalSource
PathCapability
PowerCalibrationType
RelayPosition
SCXI1124Range
ScanRepeatMode
ShuntElementLocation
ShuntResistorSelect
SoftwareTrigger
SwitchChannelUsage
TaskState
WatchdogTaskAction
WaveformAttributes
_Callback

2. Missing enum values -> These enum values are not used in nidaqmx-python. Hence removed
   BridgeConfiguration(QUARTER_BRIDGE_120_OHM_COMPLETION_RESISTOR,QUARTER_BRIDGE_350_OHM_COMPLETION_RESISTOR)

3. Docstrings differences -> These enum have docstrings differences

DataTransferActiveTransferMode
EncoderType
LoggingMode
OverWtiteMode
ResistorState
TorqueUnits
WriteBasicTEDSOptions

[zhindes]

The generated code changes look great, thanks for all the hard work there. Once Brad is happy with the generator changes, I'll be happy :)

[zhindes]

I'll merge once Brad gives his approval!

[MounikaBattu17]

The newly added 'python_description' in enums.py and 'python_enum' in attributes.py is handled in grpc-device ni/grpc-device#886

[bkeryan]

Approved with suggestions.

[MounikaBattu17]

@zhindes Brad has given his approval, can you please merge this PR?