Modernize build#1
Draft
efredriksson wants to merge 9 commits into
Draft
Conversation
…IFEST.in - Add pyproject.toml with [build-system] (meson-python), [project] metadata (description, license, authors, classifiers, urls), runtime dependencies, and PEP 735 [dependency-groups] (test + dev). - Remove legacy setup.py / setup.cfg / MANIFEST.in. - Add .env to .gitignore. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add meson.build and meson.options driving the meson-python backend. - Move src/* into src/assimulo/ so meson-python installs as a regular package; move examples/ into src/assimulo/examples/ so they're shipped with the wheel. - Wire up Cython extensions (sundials.pyx, kinsol.pyx, euler.pyx, sdirk_dae.pyx, special_systems.pyx, support.pyx, etc.) via meson. - Add tools/f2py_wrapper.py so meson can drive numpy.f2py for the Fortran solvers (dopri5, rodas, radau5, radar5, odepack, odassl, dasp3, glimda). - thirdparty: minor portability fixes — ASCII-clean glimda_complete.f, fix radar5.f90 intent warning that's an error with modern gfortran. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Dockerfile: build SUNDIALS (Modelon fork v2.7.0-3) and SuperLU_MT from source into /usr, with OpenBLAS as the BLAS provider. Embed SuperLU_MT + OpenBLAS into the SUNDIALS shared libs so .so files are self-contained. uv binary copied in for `make compile-deps`. - Dockerfile.manylinux: parallel manylinux image with the same SUNDIALS + SuperLU pre-installed, so cibuildwheel can produce manylinux wheels without rebuilding the deps each run. - tools/wheels/build_dependencies.sh: shared dep-build script reused by both Dockerfiles and the manylinux wheel pipeline. - tools/wheels/build_dependencies_windows.sh + repair_windows.ps1: Windows equivalents — build SUNDIALS under MSYS2 UCRT64; repair wheels via delvewheel. - Makefile: docker-based build/test/shell/wheel/wheel-cibw/wheel-portable targets; build-dev for incremental editable installs; build-dev-image / build-manylinux-image to (re)build the images; compile-deps regenerates requirements.lock via uv. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- pyproject.toml [tool.cibuildwheel] + per-platform sections: build cp311/312/313; skip win32/i686/musllinux; smoke-test each built wheel via pytest (test-groups = ["test"]). - Linux: use the assimulo-manylinux image (SuperLU + SUNDIALS already installed at /usr); auditwheel repair for portability. - Windows: build SUNDIALS via MSYS2 UCRT64 in the workflow first, then cibuildwheel; delvewheel repair via repair_windows.ps1. - .github/workflows/wheels.yml: per-Python matrix (sparse PR / full master via `on: all` vs `on: master`); push restricted to master/main/beta/tags; workflow_dispatch supports publish + test_release (rewrites name to assimulo-testing). - upload_pypi: OIDC Trusted Publisher to PyPI on tag pushes. - RELEASING.md: documented release flow. - Remove legacy .github/workflows/build.yml. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- requirements.lock: uv-compiled dev/test environment pin so the dev image reproducibly installs the same versions. - CLAUDE.md: document the meson-python build, key constraints (thirdparty/ untouched, .pyx files need rebuild, always use `make build`), test command, dependencies. - CHANGELOG: note the build-system migration. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
6395d73 to
7370ed3
Compare
…mJSON)
Matrix changes (.github/workflows/wheels.yml):
- Add cp314 for Linux x86_64, Linux aarch64, and Windows amd64.
- Add Linux aarch64 lane (cp311-cp314) on ubuntu-22.04-arm runners.
- PR matrix: cp311 + cp314 on Linux x86_64 and Windows (oldest+newest,
fast feedback). All other rows run on push to master/beta/tag and on
workflow_dispatch.
The earlier attempt used `if: matrix.on == 'all' || ...` on the job
itself, but GitHub Actions does not expose the `matrix` context inside
`jobs.<id>.if` (only inside env, runs-on, steps.*, etc), so the file
failed to parse outright with
`Unrecognized named-value: 'matrix'`. PyFMI's wheels.yml has the same
broken pattern and was the source of the copy.
Replaced with a `config` job that emits the matrix JSON based on
github.event_name; `linux` and `windows` jobs consume it via
`include: ${{ fromJSON(needs.config.outputs.X) }}`. Single source of
truth for the matrix; no duplicated job definitions.
Dockerfile.manylinux: introduce `ARG ARCH=x86_64` so the same Dockerfile
builds either arch; the linux job passes `--build-arg ARCH=${{ matrix.arch }}`
to docker build.
pyproject.toml: add `cp314-*` to [tool.cibuildwheel].build so cibw picks
up the new Python.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
b66ef73 to
2d63093
Compare
…ture The test classes had: @classmethod @pytest.fixture(autouse=True) def setup_class(cls): cls.X = ... Two problems: 1. @pytest.fixture on top of a method whose name is the xunit setup_class hook is non-idiomatic and was driving pytest into a code path that crashes on CPython 3.14: pytest 8.4+ wraps fixture-decorated functions in a FixtureFunctionDefinition, and pytest's xunit setup code does `func.__code__.co_argcount` on it. 3.14 attribute lookup no longer falls through the wrapper, so `AttributeError: 'FixtureFunctionDefinition' object has no attribute '__code__'` -> 271 errors on the cibw cp314 smoke test. 2. setup_class runs once per class, but the tests mutate self.simulator (e.g. simulator.h = 1.0, simulator.simulate(...)), so per-class setup leaks state between tests. The original autouse=True was masking this by re-running the function before every test. The documented pytest xunit hook for per-test setup is setup_method. Drop both decorators, rename to setup_method(self), and replace cls with self in the body. Behaves the same as before (fresh per-test state) and parses cleanly on cp314. Verified locally: 331 passed, 4 skipped on both CPython 3.12 (make test) and CPython 3.14.5 with pytest 9.0.3 (built assimulo for cp314 inside the dev container). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2d63093 to
63927e1
Compare
The matrix commit set manylinux-x86_64-image only, so cibw silently fell back to the upstream quay.io/pypa/manylinux_2_28_aarch64 for the new aarch64 lane. That image doesn't have SUNDIALS preinstalled, so the meson build immediately failed with `SUNDIALS not found: could not locate cvodes/cvodes.h`. The Dockerfile.manylinux already builds for either arch (via ARG ARCH); the wheels.yml step tags it `assimulo-manylinux` regardless of arch on the aarch64 runner. Just needed to point cibw at it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bump version to 3.9.0b2 and add a CHANGELOG section covering changes since 3.9.0b1: cp314 + Linux aarch64 wheel matrix and the setup_method test-fixture cleanup. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
96d339b to
e91a02c
Compare
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.
No description provided.