upstream fsspecstore failures

[d-v-b]

Getting failures in tests/test_store/test_fsspec.py::test_wrap_sync_filesystem, not sure what the underlying issue. The relevant test is here:

zarr-python/tests/test_store/test_fsspec.py

Lines 247 to 254 in 96c9677

	def test_wrap_sync_filesystem():
	"""The local fs is not async so we should expect it to be wrapped automatically"""
	from fsspec.implementations.asyn_wrapper import AsyncFileSystemWrapper
	store = FsspecStore.from_url("local://test/path")
	assert isinstance(store.fs, AsyncFileSystemWrapper)
	assert store.fs.async_impl

Does anyone know why this might fail for python 3.13? this is probably due to unreleased changes in fsspec

@martindurant any ideas for how we should change this test?

[martindurant]

I think fsspecStore should explicitly pass asynchronous=True when using AsyncFileSystemWrapper. I note that this isn't actually a failure but a warning, but still.

The trouble is, that the intent is to call the filesystems in async contexts (coroutine), but creating the FS is happening in blocking code. To get this specific test to pass, you could simply mark it async, but I think it's best to be explicit.

(previously, AsyncFileSystemWrapper was always asynchronous, but it ought to be callable from blocking code too, not least by kerchunk)

[d-v-b]

can you explain what this test actually does? from what I can tell AsyncFileSystemWrapper is imported but unused. Does something magic happen at import time there?

[martindurant]

Is is used in the isinstance, no? The point is, that although a file: URL is passed, you get an async wrapped instance back, not LocalFileSystem.

[d-v-b]

aha somehow my eyes slid over the isinstance. in any case, this failure is blocking all PRs now so fixing this is very high priority

[d-v-b]

regardless of the resolution of this particular test failure, I'm pretty sure PRs should not be blocked because of changes in our upstream dependencies

[d-v-b]

in the interest of speed I committed the suggested fix to an open PR: eb6b2d8

[d-v-b]

closed via #2851