(chore) use pixi for building

[d-v-b]

Adds pixi for building the project. On my linux desktop, everything compiles with
pixi run pip install -v -e '.[test,test_extras,msgpack,crc32c,pcodec,zfpy]'.

[d-v-b]

not sure if adding the blosc dep here is correct, since we are vendoring it (cc @jakirkham)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.74%. Comparing base (3cf8ab1) to head (2635279).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #704   +/-   ##
=======================================
  Coverage   99.74%   99.74%           
=======================================
  Files          63       63           
  Lines        2753     2753           
=======================================
  Hits         2746     2746           
  Misses          7        7           

[d-v-b]

cc @mkitti in case you have any advice

[mkitti]

not sure if adding the blosc dep here is correct, since we are vendoring it (cc @jakirkham)

I'll just point out that blosc is not even a dependency of the numcodecs package in conda-forge:
https://github.com/conda-forge/numcodecs-feedstock/blob/main/recipe/meta.yaml

I think this situation is a very weird. We're not even modifying the vendored blosc build here.

In contrast, the blosc package in conda-forge depends on lz4-c, snappy, zlib, and zstd packages, as this package should.
https://github.com/conda-forge/blosc-feedstock/blob/main/recipe/meta.yaml

That said, I have no idea how one would have those dependencies in PyPI via wheels.

[martindurant]

cramjam, anyone?? This would just be the reason for them to solidify the blosc backend, but they have all the others in a statically-linked wheel

[mkitti]

statically-linked wheel

Is a big statically-linked wheel the ideal here?

[martindurant]

Is a big statically-linked wheel the ideal here?

If you're worried about dependencies, packaging and how to link to system libs, I suggest that yes. I note that cramjam is ~2MB. Also, zarr likes rust crates, and cramjam can be called directly from rust, and also return python-consumable buffers.

[mkitti]

I took a look at libcramjam. I can already see several major issues. For example, I do not see checksum options for Zstandard. Now in certain circumstances, perhaps this could be fine if we had a plugin system that allowed for multiple implementations of the same codec.

I think I would much rather have a direct dependency on libzstd rather than going through another intermediary.