Pin numcodecs to version that support python 3.10#549
Pin numcodecs to version that support python 3.10#549robertmaynard wants to merge 8 commits intorapidsai:branch-24.12from
Conversation
robertmaynard
added
bug
bdice
left a comment
bdice
left a comment
There was a problem hiding this comment.
Can we allow newer numcodecs versions on newer Python versions? Why is the upper bound necessary? Are there significant incompatibilities between 0.13 and 0.14?
Also needs an update here:
kvikio/conda/recipes/kvikio/meta.yaml
Line 74 in d40b7e4
robertmaynard
force-pushed
the
fea/pin_numcodecs
branch
from
864e382 to
d8dd17d
Compare
Co-authored-by: Bradley Dice <bdice@bradleydice.com>
The 0.14 pypi package doesn't offer python 3.10 support. Outside of that I have no idea what kind of compatibility there is between releases. |
jakirkham
left a comment
jakirkham
left a comment
There was a problem hiding this comment.
Thanks Rob! 🙏
Added suggestions below for the pinnings. Think we need them a bit tighter
Co-authored-by: jakirkham <jakirkham@gmail.com>
This is a good question. Perhaps first it is helpful to provide some context around the existing pin? We added this pin due to a bug in Numcodecs' entrypoint handling logic that occurred in As to newer versions of Numcodecs, periodically it does add new optional codecs. Sometimes there are small fixes or improvements to existing ones. The API has been pretty stable for a while Looking at the diff between 0.12.1 and 0.14, it appears Python 3.10 was dropped (as discussed above), some dependencies were bumped or new versions supported (like NumPy 2), Zarr v3 (unreleased) support was added, a new cyclic redundancy check (CRC) with optional dependency was added, existing CRCs got a new optional flag, a performance fix to the Think the real question is, are we ok with having some drift between what our oldest supported Python version (currently 3.10) and what our newest supported Python version (currently 3.12) can be installed with? And if so, are there any changes we may need to make elsewhere to adapt to this reality? If not, should we start constraining all our dependencies based on the oldest Python version we support (and when do we refresh them)? Admittedly we might want to have this discussion in somewhere more general than this PR for greater visibility and easier referencing. Though wanted to follow up here since this is where the questions came up |
Yes, we are usually happy with allowing drift here. If we pin all our dependencies to only those version ranges that work with all our supported Python versions, we would be too tightly pinned for broad compatibility with the Python ecosystem. If the numcodecs APIs we use are compatible with 0.13 and 0.14, we should not exclude 0.14. |
|
I have expanded the comment in the |
bdice
left a comment
bdice
left a comment
There was a problem hiding this comment.
I have expanded the comment in the
dependencies.yamlwith more context on the pinning.
@robertmaynard Did you push? I don't see the context / comments. Blocking merge until we can figure out why this needs the upper bound.
Somehow didn't push. Updated now |
Updated to allow all version >= 0.13.0 |
There was a problem hiding this comment.
Why is this PR needed at all? The existing pinnings should be resolvable with Python 3.10, which is the PR title's stated goal. Do we need >=0.13 for some feature used in the kvikio codebase? If so, what? numcodecs version 0.12.1 should still suffice for Python 3.10 users, as far as I can tell. Also, the PR still lacks a description.
From above,
AIUI Rob is keeping with that and simply bumping the minimum version past the problematic version giving us 0.13
I would like a specific reason why 0.12.1 is not viable before bumping the lower bound.
4 participants
No description provided.