Davis Bennett

I can replicate this locally. `store.close` is [quite minimal](https://github.com/zarr-developers/zarr-python/blob/0e186719ed1750f3ba43ac18cb95c15305ab97e5/src/zarr/abc/store.py#L219) so I think our problem lies elsewhere. I will investigate.

> Since mypy runs as part of pre-commit anyway, how about just getting rid of the GitHub actions mypy stage? We don't run pre-commit as part of CI (and I...

> pre-commit is running in the CI (as seen in this PR, but maybe only on PRs? pre-commit.ci is faster than GH Actions so it should be preferred if there...

I'm open to either running mypy in pre-commit or as a stage in CI, but it doesn't seem like we need to run it in both places. It looks like...

Does the version of python mypy is running on matter? I thought mypy was configured to type-check against a specific python version in [`pyproject.toml`](https://github.com/zarr-developers/zarr-python/blob/ce6fcbbee24f4429a740963cec8b239a0b76cd34/pyproject.toml#L151)

> OK, so the problem with the tests, is that they call get/set in blocking sync code, but the store implementation works in async mode. The test instance is created...

an alternative is to revisit #146 and make these arrays smaller

I think this is basically finished. A summary of the changes: - Since the static fixtures are only used by the v2 tests, I moved them all to `tests/v2/fixture` -...

In a separate effort, I just checked auto-generated fixture files into version control by mistake again :face_exhaling: can we get some eyes on this PR so we can fix this...

to summarize some comversation from #1804, one approach would be to import all of this stuff from fsspec, and implement as little as possible within `zarr-python`. This would be expedient,...