Skip to content

scipp: Add version 26.8.0 - #3086

Draft
luhenry wants to merge 3 commits into
mainfrom
scipp
Draft

luhenry wants to merge 3 commits into
mainfrom
scipp

Conversation

@luhenry

@luhenry luhenry commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

Multi-dimensional labeled-array library with a pybind11/scikit-build-core C++ core; its own CMake fetches and builds units/Boost/Eigen3/oneTBB from source at configure time, so no system package is required. Upstream publishes no riscv64 wheel.

Mirrors upstream's wheel.yml.

Differs from upstream

  • CMAKE_POLICY_VERSION_MINIMUM=3.5 - our registry's pip-resolved cmake (4.0.3) is newer than the CPM-fetched dependencies' own cmake_minimum_required floor

Testing

  • same as upstream

License: Wheel statically links units (BSD-3-Clause), Boost headers (BSL-1.0) and Eigen3 (MPL-2.0), and dynamically links oneTBB (Apache-2.0, shipped as libtbb.so); upstream ships no licence text for any of them, so the build adds it.

Patches

  • 0001-Widen-license-files-to-cover-vendored-CPM-dependenc.patch - To upstream. license-files is an explicit PEP 639 list, so the above licences are silently dropped without widening it.

Multi-dimensional labeled-array library with a pybind11/scikit-build-core
C++ core. lib/cmake/scipp-cpm.cmake fetches and builds llnl/units, Boost
headers, Eigen3, GoogleTest (test-only) and oneTBB from source for every
wheel build, so the port needs no system TBB/Eigen/Boost package; oneTBB
2023.1.0 already builds and publishes for riscv64 in this registry,
confirming the toolchain handles it.

license-files is an explicit PEP 639 list, so the vendored
units/Boost/Eigen3/TBB licences (none of which ship in any published
wheel) need widening that list rather than just dropping files at the
root.
luhenry added a commit that referenced this pull request Oct 13, 2026
@luhenry
luhenry marked this pull request as draft October 14, 2026 11:33
@luhenry
luhenry marked this pull request as ready for review October 22, 2026 02:56
@luhenry luhenry closed this Oct 22, 2026
@luhenry luhenry reopened this Oct 22, 2026
@luhenry
luhenry marked this pull request as draft October 22, 2026 03:13
The riscv64 build of one interpreter takes ~2h55m, so every job hit the
180-minute timeout during the test step. The patched checkout is dirty,
so setuptools_scm named the wheel 26.8.1.dev0+g<sha>.d<date>; pin it with
SETUPTOOLS_SCM_PRETEND_VERSION_FOR_SCIPP and drop the now-unneeded full
history fetch. The test venv also pulled the matplotlib 3.11.2 sdist
(and would do the same for pillow and, on cp314t, hypothesis), so extend
PIP_ONLY_BINARY to the native test dependencies our registry provides.
cp312/cp314 CI failed 22 of upstream's own tests with DTypeError (add_equals,
copy, concat, ... "does not support dtypes 'int64', 'float64'"). Reproduced
against the official x86_64 PyPI wheel: those same operations work there, so
this isn't a riscv64 codegen issue.

Root cause: pyproject.toml's build-system.requires pins pybind11 to no
version, so pip resolves the newest at build time. pybind11 3.x changed
overload resolution for a plain Python int against overloads registered as
(double, int64_t) in that order -- exactly how bind_operators.h registers
Variable's scalar arithmetic. 2.x picks int64_t for the int; 3.x now picks
double, silently promoting int-valued scalars/results to float64 throughout
scipp's Python layer. Confirmed with a minimal pybind11 2.13.6 vs 3.1.0
repro using the same overload order.

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