Skip to content

fix: use cibuildwheel for building PyPI wheel - #126

Open
SYMSCAE wants to merge 7 commits into
diffpy:nanobind_migration_testfrom
SYMSCAE:cibuildwheel
Open

SYMSCAE wants to merge 7 commits into
diffpy:nanobind_migration_testfrom
SYMSCAE:cibuildwheel

Conversation

@SYMSCAE

@SYMSCAE SYMSCAE commented Nov 8, 2026 •

Copy link
Copy Markdown

This PR makes pyobjcryst use the shared wheel-building workflow. Resolves #125.

  • TODO: switch link back to the upstream repo once merged

SYMSCAE and others added 4 commits November 3, 2026 10:13
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The published wheels needed libObjCryst/libboost_python (Linux, macOS,
Windows) from a conda environment: the old shared wheel workflow ran
auditwheel and then removed the bundled libraries and pointed RPATH at the
conda prefix. The nanobind build links ObjCryst++, cctbx and newmat
statically and Boost is header-only, so build the wheels with cibuildwheel:

- add [tool.cibuildwheel] (cp312-cp315; manylinux x86_64, macOS native,
  Windows AMD64; tests run on every wheel)
- use the cibuildwheel shared workflow from SYMSCAE/release-scripts until
  it is released in scikit-package/release-scripts@v0
- derive the version from git tags with setuptools-scm instead of the
  static 2026.2.0rc0 placeholder
- declare packaging as a runtime dependency (used by powderpattern)
- trim unused ObjCryst++ submodule parts from the sdist
- guard the GCC-only -O0 flag and add MSVC settings in CMakeLists.txt
- ship the licenses of the statically linked code in the wheel

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@SYMSCAE

SYMSCAE commented Nov 8, 2026 •

Copy link
Copy Markdown
Author

@vincefn Please see if this looks good, I'll change the link and mark it ready once latest v0 is available. For your reference the generated wheels and test results (3.15) are here https://github.com/SYMSCAE/pyobjcryst/actions/runs/42438327523.

@vincefn

vincefn commented Nov 8, 2026

Copy link
Copy Markdown
Collaborator

LGTM - I did not have the time to test the wheels (leaving for a worshop in Beijing later today), though.

@SYMSCAE
SYMSCAE marked this pull request as ready for review November 10, 2026 02:42
@SYMSCAE

SYMSCAE commented Nov 10, 2026

Copy link
Copy Markdown
Author

@vincefn @sbillinge PR ready for review.

@sbillinge sbillinge left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please see inline comment.

Comment thread requirements/pip.txt
@@ -1,3 +1,4 @@
setuptools
numpy
packaging

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these seem to be all build tools. We normally use pip.txt for pip-specific installation packages to run the code, not to build it. I think we need to change the name of this to requirements/build.txt and put all the build stuff in there. Then you the workflows can pip install from build.txt

@clemisch

Copy link
Copy Markdown
Contributor

I looked at which compilation flags for numerical code this wheel would be built with. Only cmake.build-type = "Release" is set which leads to -O3 -DNDEBUG. That is fine in my eyes.

But it made me aware that previously, objcryst came from libobjcryst's scons build whose default build=fast compiles with -O3 -ffast-math. ffast-math removes isnan/isinf checks. objcryst uses them in the LSQ singular-value check in LSQNumObj.cpp#L271 so I assume -ffast-math wasn't intentional?

I guess I want to ask: have we thought about which number-crunching compilation flags we want, and which ones we currently have?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants