-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
US1198694: add nidcpower.Session.get_channel_names()
#1578
US1198694: add nidcpower.Session.get_channel_names()
#1578
Conversation
Can one of the admins verify this patch? |
FYI merge conflict @luisgomes252 |
nidcpower.Session.get_channel_names()
ok to test |
Codecov Report
@@ Coverage Diff @@
## master #1578 +/- ##
==========================================
- Coverage 91.68% 91.67% -0.01%
==========================================
Files 20 20
Lines 3463 3509 +46
==========================================
+ Hits 3175 3217 +42
- Misses 288 292 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
ok to test |
test this please |
@luisgomes252, a system test is failing:
|
Please update the description and referenced issue. Also, you can use a particular format to auto-close the issue when PR is merged: https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue |
Linter is complaining:
|
Argh. I keep doing this. Where did you go to see the Linter output? |
Here's the link to it: https://travis-ci.org/github/ni/nimi-python/builds/768570772 |
…peated capabilities
…on_name_override` and 2. avoid mixing camel-cased and snake-cased parameter names when comparing them
test this please |
build/helper/metadata_add_all.py
Outdated
@@ -271,7 +275,11 @@ def _add_render_in_session_base(f): | |||
def _add_is_repeated_capability(parameter): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole method is one big hack. We're inferring if a parameter is a repeated capability based on the name of the parameter; unless explicitly denoted. There are historical reasons for it, but I strongly question it nowadays:
Shouldn't we fix this in metadata? Then (I think) we can remove the inferring code and we can remove all this camel case conversion business.
Here's the thing: converting snakecase_to_camelcase in order to reverse the python name is a bit sketchy. It assumes that python name to C name are always camelCase to snake_case. Which happens to be true right now but doesn't really have to be true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we fix this in metadata? Then (I think) we can remove the inferring code and we can remove all this camel case conversion business.
Agreed, that the right fix, but it involves retrofitting metadata for all the drivers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Between the comments in this PR, and now the ones here in this PR, this relatively small user story is beginning to feel like a giant exercise of pulling at threads to see how can much can be unraveled. I won't dispute that there was some technical debt in the code that should probably be addressed at some point -- although I'm not the expert here, I can certainly agree that making assumptions on repeated capabilities based on the name of the parameter doesn't sound great. But I really wonder whether an "inner source" project in which we were asked to help complete the CXP API changes for nidcpower is the best vehicle for solving all this tech debt. After all, we also have a lot of tech debt in TSM that is waiting for attention too. The user story was ostensibly about adding support for instrument-based repeated capabilities for attributes (not even for function parameters). Here we are, almost a month later, and I'm no longer sure what the scope of the user story is any more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I stand corrected. This PR isn't even for the repeated capabilities user story (it's been so long, all these PRs are beginning to blur into each other). This one was just for the get_channel_names
entry point, which isn't even related to repeated capabilities. It just exposed this issue because I needed to add support in the metadata for python_name
in function parameters, which then introduced the need to update the _repeated_capability_parameter_names
looksups . So I guess it's more relevant to Marcos' comment than my first comment implied. But we're still pretty far afield from the original user story.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spoke with @luisgomes252 offline and suggested to remove the workaround in _add_is_repeated_capability
and add is_repeated_capability = false
to nidcpower metadata to prevent the rep cap tip from getting added to the docstring.
The inferring logic will still be present and we should clean it up, not that's outside the scope of this PR.
Even setting is_repeated_capability = false
can be done in a separate PR since others are blocked on this PR going in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the conversation with @sbethur, I've reverted the changes that I had made to use the python_name metadata in determining whether to add the repeated capability. Currently, get_channel_names is incorrectly being generated with metadata, but I'll fix that by updating the dcpower metadata in a subsequent PR so that I can get this one submitted as soon as possible, because a) other PRs are being gated by this one, and b) if I have to grab a new metadata export, that will also pull in a bunch of unrelated changes into this diff. So I'd like to split the PRs, if possible. @marcoskirsch: if you agree, and you have no other objections, please approve this PR when you have a chance.
test this please |
…feedback. I will fix the incorrect repeated capability for the parameter names later, by adding metadata is_repeated_capability tags to the get_channel_names parameters.
test this please |
nidcpower.Session.get_channel_names()
nidcpower.Session.get_channel_names()
What does this Pull Request accomplish?
Add get_channel_names() for NI-DCPower API
List issues fixed by this Pull Request below, if any.
Closes #1588
What testing has been done?
Added new system test and ran all unit tests. System tests will be run by CI.