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

Activate Python 3.9 #859

Merged
merged 7 commits into from
Nov 15, 2021
Merged

Activate Python 3.9 #859

merged 7 commits into from
Nov 15, 2021

Conversation

joshmoore
Copy link
Member

@joshmoore joshmoore commented Oct 22, 2021

In an attempt to track down #858
Closes #629

TODO:

  • GitHub Actions have all passed
  • Test coverage is 100% (Codecov passes)

@jakirkham
Copy link
Member

Thanks for starting this Josh 😄

Probably need to bump or relax the numcodecs requirement on CI

@joshmoore
Copy link
Member Author

Do you know the reasoning behind the 0.6.4 pins, @jakirkham ?

@joshmoore
Copy link
Member Author

Ok. So the codecov failure is the same as #811 I assume if you have any ideas, @jakirkham.

I'll fix the py39/numpy1.17 filtration problem (though maybe I just bump to numpy 1.18 ...)

@joshmoore joshmoore mentioned this pull request Oct 25, 2021
@jakirkham
Copy link
Member

Do you know the reasoning behind the 0.6.4 pins, @jakirkham ?

My guess is Matthias had some issues on CI and pinned it to fix them. Not really sure. PR ( #674 ) shows they have been here since adding GH Actions. Dropping them makes sense.

Ok. So the codecov failure is the same as #811 I assume if you have any ideas

No new thoughts.

@joshmoore
Copy link
Member Author

No new thoughts.

Looking a little closer, it looks like self.nblocks always equals 1 for PartialReadBuffer. cc @andrewfulton9
in case that raises any flags.

@joshmoore
Copy link
Member Author

Ok. Now down to just the codecov issue. The next clue in debugging is that:

        nbytes, self.cbytes, blocksize = cbuffer_sizes(header)

appears to now return matching values for nbytes and blocksize with the numcodecs update. That feels significant. Not sure if related to zarr-developers/numcodecs#283

@andrewfulton9
Copy link
Contributor

@joshmoore, sorry I missed my mention earlier. It looks like something in has changed to cause nbytes to always be the same as blocksize. It definitely could be zarr-developers/numcodecs#283. I'll have to look closer to be sure though.

@jakirkham
Copy link
Member

Oh interesting, meaning that Blosc may have changed something, which is affecting us here?

@andrewfulton9
Copy link
Contributor

andrewfulton9 commented Nov 12, 2021

It looks like maybe Blosc has changed the default to just use 1 block if blocksize isn't defined so nbytes will equal blocksize by default, where previously it used to use some default (or tried to guess an optimum) blocksize. In TestArrayWithFSStoreNested I just used the default block object so that is probably why nbytes always equals blocksize now. I can make a PR defining a blocksize there to see if that fixes it.

@jakirkham
Copy link
Member

Think that would be helpful. We'd like to keep the partial read functionality in good working order 🙂

@joshmoore
Copy link
Member Author

With #867 merged, this is now green. Merging (but #858/debian-failure) is still a mystery.

@joshmoore joshmoore merged commit 1e70a3c into zarr-developers:master Nov 15, 2021
@joshmoore joshmoore deleted the py39 branch November 15, 2021 10:02
@jakirkham
Copy link
Member

Thanks Josh! 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test on Python 3.9
3 participants