Repository navigation
Reenables building MacOS PyPI package - #73
Merged
Merged
Conversation
.gitignore already uses `build*/`, so a second tree (build-debug/, build2/, a renamed one) is invisible to git but still walked by license-eye, which matched only the literal name `build`. On a configured tree that is gigabytes of CMake/FetchContent output per commit, and the walk fails outright when a concurrent build mutates it mid-scan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub only exposes a workflow_dispatch workflow once its file exists on the default branch; dispatching from the branch that adds it answers HTTP 404: workflow wheel_dryrun.yaml not found on the default branch which makes dispatch useless for the one job it was added to do -- prove the macOS wheel builds *before* anything lands on master. A push trigger scoped to this branch has no such requirement. A push event carries no inputs, so inputs.platform defaults to macos, the leg this exists to exercise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Temporary. build_pypi_dist@master currently dies before before_all with "Unsupported bash construct: 'assignment'" -- see the first dry run, 34641892205. Validate the fix here before it lands on .github master, which every repo in the ecosystem consumes at @master. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AppleClang rejects it: grid_from_integratorxx.cpp:217:32: error: reference to local binding 'molecule' declared in enclosing function 'scf::xc::GridFromIntegratorXX::run_' Capturing a structured binding is C++20 (P1091). GCC implements it, so the Linux release wheel and both Linux dev legs compile this fine. AppleClang on the macos-14 runner does not, and AppleClang is reached only by the wheel build -- cibuildwheel compiles with /usr/bin/clang++, while the macOS dev matrix uses Homebrew clang-18 and gcc-14, both of which implement P1091. So no existing job covers this compiler, and the file has been unbuildable there since it was added in #71. Binding the input to an ordinary reference first sidesteps the rule entirely and compiles under any C++17 compiler. Verified against the failing dry run, 34642262844. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Scaffolding. It did its job: three runs on a real macos-14 runner found the cibuildwheel SKBUILD_CMAKE_DEFINE quoting defect (which broke wheel builds for every repo in the ecosystem, on both platforms) and an AppleClang compile error in grid_from_integratorxx.cpp that no green job was exercising, then produced a verified macosx_14_0_arm64 wheel. Dropping it also removes the temporary @macos_wheel_fixes pin, so nothing in this branch references anything but NWChemEx/.github@master. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The last CI run on this branch predates the ecosystem config-dependency rollout finishing (NWXCMake 0.2.3 + rebuilt pluginplay/utilities/wtf/ tensorwrapper/chemist/simde). Empty commit, nothing else.
Member
Author
|
This is stuck in a cycle where the SCF version that comes in from the |
Contributor
|
🚀 [bumpr] Bumped! |
This was referenced Sep 15, 2026
ryanmrichard
added a commit
that referenced
this pull request
Sep 28, 2026
SCF#73's test_cmake_build previously failed on all four legs (Linux+macOS, both compilers) with "link interface of nwx::simde contains nwx::chemist but the target was not found" -- not the config-dependency bug NWXCMake#87/#88 already fixed, but a self- collision: the integration-testing step's `pip install nwchemex` transitively floor-pins nwchemex-scf>=0.0.57, pulling in SCF's own stale, previously-published wheel (0.0.60, predating the rollout). That stale wheel bundles the old broken two-line simdeConfig.cmake, and since it installs into the same site-packages/lib/cmake/simde/ path as the freshly-resolved nwchemex-simde 0.0.81, it clobbered the correct config. #73 merged anyway: merge.yaml doesn't run test_cmake_build, so the new release (nwchemex-scf 0.0.61, published 2026-09-15T15:18 UTC) was built clean from git master, unaffected by the collision, and its own bundled dependency configs are now correct. This empty commit re-runs test_cmake_build to confirm that installing the new self-consistent nwchemex-scf no longer clobbers anything.
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
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.
Summary
Publishes a macOS wheel for
nwchemex-scf, the only compiled repo in the ecosystem without one (0.0.60 ships manylinux + sdist only, while ten siblings all publishmacosx_*_arm64).What's here
Three changes, no scaffolding:
.github/workflows/merge.yaml— dropfilter_release_matrix, which strippedmacos-14out ofrelease_matrix. It was added for a macOS pybind11 segfault that was fixed in Fix macOS pybind11 module segfault: Python_FIND_STRATEGY=LOCATION .github#189; verified below that it does not recur in the wheel path.cxx/src/scf/xc/grid_from_integratorxx.cpp— don't capture a structured binding in the dispatch lambda. AppleClang rejects it..licenserc.yaml— ignorebuild*, not justbuild, matching.gitignore.The AppleClang bug is worth a second look
Capturing a structured binding is C++20 (P1091). GCC implements it, AppleClang does not.
No existing job compiles with AppleClang. cibuildwheel builds with
/usr/bin/clang++, while the macOS dev matrix uses Homebrewclang-18andgcc-14— both of which implement P1091 — and Linux usesgcc-14/clang-18. So this file has been unbuildable on the actual release compiler since #71 while every CI leg stayed green. Of the 20 structured bindings incxx/src, this is the only file that also contains a capturing lambda.Worth considering as a follow-up: an AppleClang leg in the macOS dev matrix, so release-compiler breakage surfaces in PR CI instead of at release time.
Verification
Proven on a real
macos-14runner before merging, via a temporary non-publishing dry-run workflow (removed in 959cf4c). Run 34644965231:macosx_14_0_arm64, matching every otherneeds_mpisibling. cibuildwheel builds11_0; delocate retags to14_0after vendoring Homebrew's MPI stack, exactly asbuild_pypi_distdocuments.import_check.pyimportedscf.cpython-312-darwin.socleanly under python.org framework CPython 3.12.pz.runtime.RuntimeView()reachesMPI_Initagainst the vendored open-mpi andscf.load_modulesregisters 31 modules, so the Linux MPI-vendoring dead end does not reproduce on macOS.Knock-on effect
pull_request.yaml:32-43documents that the absence of a macOS SCF wheel is what forcespip install nwchemexto source-build a stale sdist on macOS. Once this publishes, theallow_macos_failure: "true"masks inpull_request.yamlandnightly.yamlshould be re-evaluated — separate PR.🤖 Generated with Claude Code