Skip to content
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

Fix attribute retrieval from version-dependent icephys #264

Merged
merged 9 commits into from
Sep 23, 2022

Conversation

CodyCBakerPhD
Copy link
Contributor

@CodyCBakerPhD CodyCBakerPhD commented Sep 20, 2022

After discussing we're just going to follow KISS principles and add safe attribute access to things like this instead of getting bogged down by version specifics.

Should fix the core issue of #263 and the corresponding conda-forge issue.

@CodyCBakerPhD CodyCBakerPhD added the category: bug errors in the code or code behavior label Sep 20, 2022
@CodyCBakerPhD CodyCBakerPhD self-assigned this Sep 20, 2022
@CodyCBakerPhD CodyCBakerPhD changed the title Fix pynwb version icephys Fix attribute retrieval from version-dependent icephys Sep 20, 2022
@codecov-commenter
Copy link

Codecov Report

Merging #264 (f158d33) into dev (0719c88) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##              dev     #264   +/-   ##
=======================================
  Coverage   94.03%   94.03%           
=======================================
  Files          20       20           
  Lines        1022     1022           
=======================================
  Hits          961      961           
  Misses         61       61           
Flag Coverage Δ
unittests 94.03% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
nwbinspector/checks/icephys.py 100.00% <100.00%> (ø)

@CodyCBakerPhD
Copy link
Contributor Author

@bendichter @oruebel @rly If someone could review when any of you get a chance

@@ -6,5 +6,5 @@
@register_check(importance=Importance.BEST_PRACTICE_VIOLATION, neurodata_type=IntracellularElectrode)
def check_intracellular_electrode_cell_id_exists(intracellular_electrode: IntracellularElectrode):
"""Check if the IntracellularElectrode contains a cell_id."""
if intracellular_electrode.cell_id is None:
if getattr(intracellular_electrode, "cell_id", "") is None: # Will only be None with PyNWB>=2.1.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that this would work, but maybe a better option is to be a bit more explicit, using get_package_version(name="pynwb") < Version("2.1.0") within the check function itself.

Copy link
Contributor Author

@CodyCBakerPhD CodyCBakerPhD Sep 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that but that is precisely the precedence that leads us down a rabbit hole in the future to having to figure out which parts of which tests depend on which version of PyNWB is being used at runtime.

So it's a lot easier on us to set the precedence of just safely checking if an attribute is accessible and do an early return if not, independent of the reason that field might not be accessible.

Also, apologies - I had thought the last commit included an adjustment I made swapping it from getattr to hasattr but it didn't get pushed, my bad.

@@ -0,0 +1,32 @@
name: Past PyNWB Version
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason you are setting this up as a cron job instead of just adding it to the PR triggered workflow?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiplicity - If I include it in the main workflow we'd have (number of platforms) x (number of Python versions) x (number of PyNWB versions), which gets a bit out of hand.

This instead constrains to ubuntu-latest + Python 3.9 and then goes back as far in the version history as desired.

@bendichter
Copy link
Contributor

Right now you are detecting the version of PyNWB. Wouldn't we instead want to check the version of the nwb schema used in the NWB file?

@CodyCBakerPhD
Copy link
Contributor Author

Right now you are detecting the version of PyNWB. Wouldn't we instead want to check the version of the nwb schema used in the NWB file?

The testing suite detects PyNWB version to determine which type of in-memory object to create and determine the expected testing behavior. That's only important for the devs and the CI.

The check itself, what users will actually call, merely checks for existence of the attribute, which is the simplest approach we can take for this kind of thing. This is especially robust to any future changes to the NWB schema that might change the data model for that object or even minor adjustments to the name of an attribute.

@CodyCBakerPhD CodyCBakerPhD merged commit 2509e67 into dev Sep 23, 2022
@CodyCBakerPhD CodyCBakerPhD deleted the fix_pynwb_version_icephys branch September 23, 2022 16:16
@CodyCBakerPhD
Copy link
Contributor Author

Leaving here for provenance: this PR is a simple hotfix to allow various downstream releases to go forward.

After some discussion, we need a better long-term solution for handling and communicating NWB schema version-dependent checks. The open issue #220 and PR #225 should be a good alternative for implementing this since it's analogous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: bug errors in the code or code behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants