dask 存储库中的语义版本控制

Question

为什么 the commit 7138f470f0e55f2ebdb7638ddc4dfe2e78671403 trigger a new major version of dask since the function read_metadata is incompatible with older versions? The commit introduced the return of 4 values, but the old version only returned 3. According to semantic versioning 这不是正确的行为。

cudf 被破坏了，因为那次提交。

问题代码：

>>> import cudf
>>> import dask_cudf
>>> dask_cudf.from_cudf(cudf.DataFrame({'a':[1,2,3]}),npartitions=1).to_parquet('test_parquet')

>>> dask_cudf.read_parquet('test_parquet')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/nvme/0/vjawa/conda/envs/cudf_15_june_25/lib/python3.7/site-packages/dask_cudf/io/parquet.py", line 213, in read_parquet
    **kwargs,
  File "/nvme/0/vjawa/conda/envs/cudf_15_june_25/lib/python3.7/site-packages/dask/dataframe/io/parquet/core.py", line 234, in read_parquet
    **kwargs
  File "/nvme/0/vjawa/conda/envs/cudf_15_june_25/lib/python3.7/site-packages/dask_cudf/io/parquet.py", line 17, in read_metadata
    meta, stats, parts, index = ArrowEngine.read_metadata(*args, **kwargs)
ValueError: not enough values to unpack (expected 4, got 3)

dask_cudf==0.14 仅兼容 dask<=0.19。在 dask_cudf==0.16 中，问题已修复。

编辑：Link to the issue

Answer 1

虽然 Dask 没有关于版本字符串值的具体策略，但有人可能会争辩说，在这种特殊情况下，IO 代码是 non-core，并且主要由上游 (pyarrow) 开发推动而不是我们自己的主动。

对于您的代码损坏，我们深表歉意，当然，选择正确版本的包并期待下游包赶上来是开源生态系统的一部分。

如果您想从 dask 维护团队获得更多意见，您可能希望将此问题作为 github 问题提出。（从 Whosebug 的角度来看，这里没有太多要“回答”的）

dask 存储库中的语义版本控制

Semantic versioning in dask repository

python

dependencies

dask

cudf