We recently had breakage in the 3.1.4 release because numcodecs dropped support for crc32c, which zarr-python was relying on indirectly. This was not caught in the numcodecs tests because the zarr test environments declared a crc32c dependency explicitly.
The crc32c checksum is used by the sharding codec. since we want sharding to be central to zarr python, we need to declare our crc32c dependency explicitly and not rely on getting crc32c support installed ambiently via numcodecs.
IMO for this specific case we should implement the crc32c codec directly in zarr python and not rely on numcodecs for it at all. We can do this while remaining compatible with the numcodecs crc32c codec class.
I suspect this is the only case of an indirect required dependency, but I will search for more just to be sure.
We recently had breakage in the 3.1.4 release because numcodecs dropped support for
crc32c, which zarr-python was relying on indirectly. This was not caught in the numcodecs tests because the zarr test environments declared a crc32c dependency explicitly.The crc32c checksum is used by the sharding codec. since we want sharding to be central to zarr python, we need to declare our crc32c dependency explicitly and not rely on getting crc32c support installed ambiently via numcodecs.
IMO for this specific case we should implement the crc32c codec directly in zarr python and not rely on numcodecs for it at all. We can do this while remaining compatible with the numcodecs crc32c codec class.
I suspect this is the only case of an indirect required dependency, but I will search for more just to be sure.