Updating param name from connector_i_ds to connector_ids in RFmx VNA

[RahulBenaka]

What does this Pull Request accomplish?

For APIs in VNA with parameter name as connectorIDs (in metadata), the name was appearing as connector_i_ds in proto and respective service files. This PR aims to resolve that naming issue and correct it to connector_ids. This is achieved by adding "IDs" in the ADDITIONAL_ACRONYMS of VNA gRPC metadata in grpc-scrapigen repo and leverage that to generate 'grpc_name' field to add the appropriate name to be reflected in proto and respective service files

Why should this Pull Request be merged?

This name change from connector_i_ds to connector_ids is required for legibility and this will help us to maintain python gRPC code for RFmx use the appropriate naming convention.

What testing has been done?

Manually inspected generated files.
Copied files from grpc-device-scrapigen/out/rfmxvna/export/ to grpc-device/source/codegen/metadata/nirfmxvna/ and hardcoded these new param names by using 'grpc_name' field and built grpc-device successfully.
Manually inspected nirfmxvna.proto file.

[RahulBenaka]

Currently the Validate Python Code Job is failing at Validate examples step due to a dependency issue.

Just to give context, this was the previous run which had ran fine:

And now this step is failing as setuptools is being updated to a version greater than 81.

I believe this Bug captures this issue. So is there a way for me to lock the setuptools version to be <81?

@astarche @reckenro

FYI: @ThangamV-NI

[astarche]

Currently the Validate Python Code Job is failing at Validate examples step due to a dependency issue.

Just to give context, this was the previous run which had ran fine:

And now this step is failing as setuptools is being updated to a version greater than 81.

I believe this Bug captures this issue. So is there a way for me to lock the setuptools version to be <81?

@astarche @reckenro

FYI: @ThangamV-NI

Generally we need to move FORWARD not BACK to resolve these issues. Our examples should work with the latest stuff, so try to make that happen.

In this case that means (a) look for pinned dependencies that are on old versions (and move to new versions) and (b) consider increasing the minimum python version and the version used in these builds. python 3.9 is EoL and several deps (black and types-protobuf) have dropped support. We still support 3.9 internally at NI, but I don't think that applies to our grpc-device examples.

The issue you linked has been partially resolved, but we are missing the critical step of adding dependabot to automatically update the pinned dependencies. We also have a mix of pin semantics in examples/pyproject.toml so there are some packages that are stuck on old versions and others that are not. So, in this context, there is a (new) package that uses new setuptools and a (old) package that uses deprecated stuff from setuptools. Something like that.

Originally this code called poetry add --dev grpcio-tools mypy mypy-protobuf types-protobuf grpc-stubs to basically follow our examples setup instructions (pip install this that the-other). Unfortunately that can fail PR builds when new packages are released. If we pin dependencies in pyproject.toml AND use dependabot, we shift that failure to an async nightly build (which is great!). But what we have here is worst of both worlds.

I feel that changing examples/pyproject.toml to use ^current_latest_version is a better short-term compromise unless/until we enable dependabot. Alternatively we could pin to strict versions, but that will go stale fast.

I'm attempting that change here: #1238 . I think that is close, but I'm working through some failures.

@maxxboehme @bkeryan do you have an idea how we can schedule or make progress on enabling dependabot for grpc-device examples?

[RahulBenaka]

@astarche, I have taken your suggestion and changed pyproject.toml to use "^current_latest_version" of setuptools as a temporary fix for now. The build has passed successfully without any errors. Thank you.

[bkeryan]

Currently the Validate Python Code Job is failing at Validate examples step due to a dependency issue.
Just to give context, this was the previous run which had ran fine:
And now this step is failing as setuptools is being updated to a version greater than 81.
I believe this Bug captures this issue. So is there a way for me to lock the setuptools version to be <81?
@astarche @reckenro
FYI: @ThangamV-NI

Generally we need to move FORWARD not BACK to resolve these issues. Our examples should work with the latest stuff, so try to make that happen.

In this case that means (a) look for pinned dependencies that are on old versions (and move to new versions) and (b) consider increasing the minimum python version and the version used in these builds. python 3.9 is EoL and several deps (black and types-protobuf) have dropped support. We still support 3.9 internally at NI, but I don't think that applies to our grpc-device examples.

The issue you linked has been partially resolved, but we are missing the critical step of adding dependabot to automatically update the pinned dependencies. We also have a mix of pin semantics in examples/pyproject.toml so there are some packages that are stuck on old versions and others that are not. So, in this context, there is a (new) package that uses new setuptools and a (old) package that uses deprecated stuff from setuptools. Something like that.

Originally this code called poetry add --dev grpcio-tools mypy mypy-protobuf types-protobuf grpc-stubs to basically follow our examples setup instructions (pip install this that the-other). Unfortunately that can fail PR builds when new packages are released. If we pin dependencies in pyproject.toml AND use dependabot, we shift that failure to an async nightly build (which is great!). But what we have here is worst of both worlds.

I feel that changing examples/pyproject.toml to use ^current_latest_version is a better short-term compromise unless/until we enable dependabot. Alternatively we could pin to strict versions, but that will go stale fast.

I'm attempting that change here: #1238 . I think that is close, but I'm working through some failures.

@maxxboehme @bkeryan do you have an idea how we can schedule or make progress on enabling dependabot for grpc-device examples?

Sorry, I didn't see this reply yesterday when I commented on your other PR.

Here's what our other GitHub-hosted Python projects do:

• Use Renovate Bot to update poetry.lock
• Use >= constraints instead of ^
• Do not use poetry add
• Do not update poetry.lock in GHA workflows
• Do not use requirements.txt files

We can chat offline about how to get started with Renovate.