Fix bug when reading scalar datasets

[ehennestad]

Fix issue #120

Add a check in ZarrPy/readZarrfor whether starts, ends or strides are integers, and wrap them in a list if true.

Some alternatives:

• wrap in array to ensure type is same as what is received from MATLAB when these are non-scalar?
• simplify check and assume all is scalar if one is scalar

[krisfed]

Thank you for contributing!!! Looks reasonable to me.

Looks like we don't have workflow enabling tests to run for PRs from forks, let me fix that.

I was going to ask to add a test, but it seems currently there is no way to write a scalar dataset (with shape that is a scalar value) using this project (Is that a significant limitation?). For now, if you are ok adding starting_time or a different sample scalar dataset to test/dataFiles and adding a simple test in test/tZarrRead.m to read it, that would be great! If not, you can add a task for us to add a test later.

[krisfed]

Even if you are not able to add a test, could you please do a dummy commit to trigger the tests workflow on the PR? Thanks!

[ehennestad]

I can add a test. Being able to write scalar datasets is out of scope at the moment, we will first work against full support for read

[krisfed]

Sounds good, thanks!

Yes, sorry, didn't meant to imply you have to work on writing scalar datasets, just thinking if that's something we should look into in the future.

[krisfed]

Looks good to me!

As mentioned - would be nice to have a test though, and to make sure existing tests run fine.

Thanks for contributing!

[ehennestad]

@krisfed I finally got around to add the unit test. Sorry for the delay

[ehennestad]

Hi @krisfed! Friendly reminder on this. Sorry it sat on my side for a while, but test is in and so I just wanted to check if you have a chance to take another look. Anything else needed from me?

For context on why I'm keen: I maintain MatNWB, the MATLAB API for Neurodata Without Borders, and we're building Zarr v2 read support on top of this library.

That leads to a planning question I'd value your honest read on: what does your review/maintenance bandwidth look like going forward, and would you be open to larger contributions? I have further changes staged in a fork to cover what NWB needs, and I'd much rather upstream them and stay aligned with your roadmap than maintain a long-term fork — but I need to understand whether that's realistic before committing either way. Happy to keep PRs small and reviewable and discuss design up front.

Thanks for maintaining this — it's been useful to build on.

[jhughes-dev]

Very sorry, I didn't notice I was added for review.
You can get by with a much shorter test, but otherwise this looks great.

Thanks for doing this.

[jhughes-mw]

See comment on jhughes-dev. Was logged into the wrong account.

Accidental wrong account

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.81%. Comparing base (50c4950) to head (4a97e68).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #124   +/-   ##
=======================================
  Coverage   95.81%   95.81%           
=======================================
  Files           8        8           
  Lines         263      263           
=======================================
  Hits          252      252           
  Misses         11       11           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[krisfed]

Looks great, thank you for adding the test! Sorry for delay!

[krisfed]

That leads to a planning question I'd value your honest read on: what does your review/maintenance bandwidth look like going forward, and would you be open to larger contributions? I have further changes staged in a fork to cover what NWB needs, and I'd much rather upstream them and stay aligned with your roadmap than maintain a long-term fork — but I need to understand whether that's realistic before committing either way. Happy to keep PRs small and reviewable and discuss design up front.

Thanks for maintaining this — it's been useful to build on.

Thank you for this question and transparency, it is exciting to hear that this has been useful!
Sorry for spotty responsiveness so far - the initial developer on this project has left, and I had been out on a sick leave. We should be more responsive to PRs going forward (especially given this heads-up), and hopefully we will be able to do more development in the future too. Will look forward to further collaboration!