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

[Feature]: Raise warning when writing data with unreleased version of schema #1837

Open
3 tasks done
rly opened this issue Feb 1, 2024 · 8 comments
Open
3 tasks done
Labels
category: enhancement improvements of code or code behavior help wanted: good first issue request for community contributions that are good for new contributors priority: low alternative solution already working and/or relevant to only specific user(s)

Comments

@rly
Copy link
Contributor

rly commented Feb 1, 2024

What would you like to see added to PyNWB?

I came across a (draft) dandiset with cached core schema version "2.6.0-alpha". This is a development/unreleased version of the schema, and probably results from the author using dev branches of nwb-schema and/or pynwb. NWB files should not be released with these unreleased schema because it makes debugging difficult (that version string can correspond to multiple specs/commits), and these schema may not be compatible with pynwb due to later fixes in the schema before the official release.

Is your feature request related to a problem?

^

What solution would you like?

I think we should raise a warning if a user writes an NWB file with an unreleased version of the schema or even loads an unreleased version of the schema. Alternatively, we could put this in NWB Inspector, but I think we can and should catch it on or before write.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

@rly rly added category: enhancement improvements of code or code behavior help wanted: good first issue request for community contributions that are good for new contributors priority: low alternative solution already working and/or relevant to only specific user(s) labels Feb 1, 2024
@CodyCBakerPhD
Copy link
Collaborator

As you found this on DANDI, are you proposing too that there should be something preventing upload of such files to the archive?

A simple warning on the PyNWB side would not prevent that, but a new inspector check could

@rly
Copy link
Contributor Author

rly commented Feb 1, 2024

Good point. I think we should prevent upload of such files to DANDI. @bendichter @oruebel what do you think?

@oruebel
Copy link
Contributor

oruebel commented Feb 1, 2024

The ultimate policy decision is up to DANDI, but I agree that publishing data with alpha versions of the schema should be either blocked or at least raise a warning in the inspection phase since we can't guarantee support for alpha versions.

@CodyCBakerPhD
Copy link
Collaborator

The ultimate policy decision is up to DANDI, but I agree that publishing data with alpha versions of the schema should be either blocked or at least raise a warning in the inspection phase since we can't guarantee support for alpha versions.

cc: @yarikoptic @satra what do you guys think?

@yarikoptic
Copy link
Contributor

AFAIK ATM we do not impose any limits on versions of nwb schema in the files really... I agree indeed it could be at least some kind of a WARNING level annotation by nwb inspector... and I would not mind ERROR level for "dandi" profile to avoid cases of unloadable files the future.

@CodyCBakerPhD
Copy link
Collaborator

OK, opened NeurodataWithoutBorders/nwbinspector#432

Leaving this one here so there can be a PyNWB warning in the event more generally

@rly
Copy link
Contributor Author

rly commented Feb 2, 2024

Thanks @CodyCBakerPhD .

I just learned that when we released NWB schema 2.6.0, we (I) forgot to change the version string from "2.6.0-alpha" to "2.6.0" in the nwb.namespace.yaml file. It was correctly updated in nwb.file.yaml though (in NWBFile group spec > attribute "nwb_version"). So please note that if you are troubleshooting these files.

When checking the version string, we can add exceptions for "2.6.0-alpha", "2.0b" and any other unusual released version strings. Or we can apply this check only for schema released after now, i.e. x.y.z >= 2.7.0. The former should not be hard to do. I'll take a crack at it next week.

@rly
Copy link
Contributor Author

rly commented Feb 5, 2024

Update: I am not going to get to this this week or month. If someone else wants to take a crack at it, please feel free.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: enhancement improvements of code or code behavior help wanted: good first issue request for community contributions that are good for new contributors priority: low alternative solution already working and/or relevant to only specific user(s)
Projects
None yet
Development

No branches or pull requests

4 participants