Skip to content

pyscf: Add version 2.14.0 - #2415

Draft
luhenry wants to merge 5 commits into
mainfrom
pyscf
Draft

luhenry wants to merge 5 commits into
mainfrom
pyscf

Conversation

@luhenry

@luhenry luhenry commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

Compiles pyscf's own CMake-built libraries plus libcint, libxc and xcfun (fetched at build time), all loaded via ctypes with no CPython C-API extensions, so upstream's own wheels are py3-none-<platform> and one build serves every interpreter. Upstream publishes no riscv64 wheel.

Mirrors upstream's own release-pypi-aarch64 job.

Differs from upstream

  • ENABLE_SMD=OFF instead of upstream's Linux-job ON - keeps pyscf's own GPLv3 MNSOL solvent code out of the wheel.

Matrix: single build (py3-none), no interpreter matrix.

Testing

  • same as upstream's aarch64 job (ignores pyscf/adc, pyscf/pbc/df, pyscf/pbc/cc), plus pyscf/solvent since ENABLE_SMD is off.

License: wheel bundles libcint (Apache-2.0), libxc/xcfun (MPL-2.0) and OpenBLAS (BSD); upstream ships no licence text for any of them, so the build adds it.

Built on cp312.

Upstream ships py3-tagged wheels that are platform-specific fat wheels: no
CPython C-API extensions (no Python.h anywhere in pyscf/lib), just CMake-built
shared libraries (own code, libcint, libxc, xcfun) loaded via ctypes, so one
build serves every interpreter, matching upstream's own aarch64/x86_64 Linux
wheel jobs. libcint's x86 SIMD file (gout2e_simd.c) is not wired into its
build; pyscf's own C sources gate every x86-specific flag behind a compiler
check, so nothing here is riscv64-blocking.

Bundles LICENSE files for libcint (Apache-2.0), libxc/xcfun (MPL-2.0) and
OpenBLAS (BSD), none of which upstream's own official wheels carry despite
linking all four. ENABLE_SMD is left off (matching upstream's own macOS
build), which also keeps pyscf's own GPLv3-licensed MNSOL solvent code
(pyscf/lib/solvent) out of the wheel.
luhenry added a commit that referenced this pull request Sep 28, 2026
@luhenry
luhenry marked this pull request as draft September 28, 2026 07:11
@github-actions

github-actions Bot commented Sep 28, 2026 •

Copy link
Copy Markdown
Contributor
PR Preview Action v1.8.1

QR code for preview link

🚀 View preview at
https://riseproject-dev.github.io/python-wheels/pr-preview/pr-2415/

Built to branch gh-pages at 2026-10-02 00:43 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

/work/pyscf still holds pyscf.egg-info from the --no-clean pip wheel
build step. python -c puts cwd on sys.path[0], so
importlib.metadata resolves that stale egg-info (no licenses/
subdirectory) instead of the installed wheel, and the licence
assertion sees an empty set. Move the check after the cd /tmp the
later import pyscf smoke test already relies on for the same
reason.
pytest's --import-mode=importlib still imports a nested test's ancestor
packages straight from the checkout's __init__.py by walking up the
filesystem, bypassing the installed wheel (gotcha 616). The checkout's
unrepaired .so then fails to find libopenblas.so.0, aborting
pyscf/lib/__init__.py partway through and cascading into 336
unrelated-looking AttributeErrors.

Fix by moving /work/pyscf/pyscf to /work/pyscf/pyscf-src right before the
pytest invocation and repointing the collection target and --ignore= globs
at the new path, the same approach gotcha 148 already uses.
…ling module not part of the installed wheel

grad/test/test_ucasci.py does `from pyscf.grad.test.test_casci import
_check_fd_grad`, relying on pyscf.grad.test being an importable package -
which it is when running against the in-place checkout, but the installed
wheel (which the collected tests otherwise correctly exercise per gotcha
616) does not ship its own test suite as an importable subpackage.

luhenry commented Sep 30, 2026

Copy link
Copy Markdown
Member Author

Build pyscf 2.14.0 py3-manylinux_riscv64 (run 36691144536) shows conclusion: failure, but the job detail shows the Test wheel step stuck in_progress with no completed_at, and the following Post Checkout step pending — the runner died mid-test after the wheel itself built successfully (Build wheel completed clean at 12:33 UTC, ~3h50m in). This is a runner failure, not a test failure. Re-queued via rerun_failed_jobs.


Generated by Claude Code

luhenry commented Oct 1, 2026

Copy link
Copy Markdown
Member Author

Correction to my earlier comment here: that was a misdiagnosis. The job wasn't a dead/hung runner - it was making genuine progress through pytest the whole time and got cancelled by hitting its own timeout-minutes: 720 (12h) ceiling, at 88% of the suite. Confirmed from the raw log: steady dot-progress with real timestamps throughout, ##[error]The operation was canceled. at exactly ~12h00m from start, no stall.

Two separate problems, not one:

  1. Raw runtime. 88% of the suite in 720 minutes extrapolates to roughly 13-14h for a full pass - this is a genuinely large, slow test suite on this hardware, not a timeout picked too tight by accident.
  2. Real failures already present. Several F marks appear scattered through the run (around the 45%, 49%, 52%, 67% and 70% marks) well before the timeout. -q suppresses names until the final summary, which the timeout cut off before it printed, so I can't name the failing tests from this run - only that they exist and aren't a product of running out of time.

Given a rebuild here costs ~14h for an uncertain result, I'm not re-running blindly a third time. Next step for whoever picks this up: rerun with -v instead of -q (or route failures to a file as they happen) so the specific failing tests are visible even if the suite times out again, and separately decide whether timeout-minutes needs raising past 720 or the ignored-paths list needs to grow to match upstream's own actual passing scope more closely.


Generated by Claude Code

@luhenry
luhenry force-pushed the main branch 3 times, most recently from 39fb7ba to a75cf68 Compare October 1, 2026 15:22
Run 36691144536 attempt 2 was not superseded or cancelled by hand: the
build job hit its own timeout-minutes: 720 exactly 12h after it started
(17:02:49Z -> 05:03:05Z), with pytest still making steady progress at 88%
of the suite. The wheel build takes 3-4h on the riscv64 runner and the
test suite (upstream's linux-build-aarch64 CI selection, single-threaded)
needs roughly 10h on top, so the job cannot fit in 720 minutes. 1440 is
the ceiling the repo's other long single-job builds use.

Also drop -q: it hides test names until the final summary, which the
timeout cut off, so the ~14 failures already visible in that run could not
be identified. Default verbosity prints each test file as it runs, as
upstream's own pytest invocation does.

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.

1 participant