Bump version to 1.0.9 - #71
Merged
Merged
Conversation
Syncs the version string across pyproject.toml, setup.py, and daisy/__init__.py (previously drifted: 1.0.8 / 1.0.8 / 1.0.0). Merging this to main will trigger the pypi-release workflow to publish 1.0.9, since 1.0.8 is already live on PyPI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pypi-release.yml only builds when the version changes, so a broken build is invisible until the very push that is meant to publish it. ci.yml does not cover the gap: it builds through CMake with -DBUILD_SING=OFF, while setup.py compiles every source in the package unconditionally. release-check.yml runs the same environment and the same build steps as the release job, then stops before twine upload. It installs the built wheel into a clean venv and searches an index with it, because daisy/__init__.py downgrades a missing extension to a warning, so a wheel whose extension does not load still imports cleanly. check_release_artifacts.py covers the rejections that a green build does not rule out: a version that disagrees between setup.py and pyproject.toml, an sdist missing sources, and a wheel tagged linux_x86_64, which PyPI refuses. It runs standalone against any dist/ directory, so a release can be rehearsed locally too.
Reading a failed job's log back needs an authenticated GitHub token, which makes a build failure awkward to diagnose from outside the browser. Tee the build output to build.log, upload it alongside dist/, and put the first error lines in the job summary so the cause is visible without scrolling the raw log.
exact_DTW_SING_new called LBDshortstreamGPUinsidedynamicratev2dtw unconditionally while its declaration sits behind #if SING_CUDA_ENABLED, so the PyPI build broke. Stub it like LBDfloatstreamGPU already is.
python -m build tags Linux wheels linux_x86_64, so add an auditwheel repair step to both workflows. auditwheel checks glibc, not CPU features, so -march=native would have turned a rejected wheel into a SIGILL on any narrower CPU; DAISY_PORTABLE_BUILD targets AVX2 instead. SIMD.hpp tested __AVX__ while the code it guards uses AVX2 intrinsics.
pybinds bound Coconut, Fresh, DumpyOS and Hercules but setup.py never compiled their sources, so the wheel failed on the first undefined typeinfo. Add them plus ds_tree and VectorDataLoader, ship *.h in the sdist, and drop the unregistered abstract base from the Hercules and DumpyOS bindings, which made module init fail once they linked.
MChatzakis
approved these changes
Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The PyPI release pipeline fails at "Build distributions" only on the main branch.
See: https://github.com/MChatzakis/DaiSy/actions/runs/30389858062