Skip to content

tetgen: Add version 0.8.4 - #3081

Draft
luhenry wants to merge 1 commit into
mainfrom
tetgen
Draft

luhenry wants to merge 1 commit into
mainfrom
tetgen

Conversation

@luhenry

@luhenry luhenry commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

Compiles PyVista's nanobind binding over Hang Si's TetGen C++ tetrahedral mesh generator. Upstream publishes no riscv64 wheel.

Mirrors upstream's build-and-deploy.yml build_wheels job, narrowed to Linux.

Differs from upstream

  • Nothing beyond the riscv64 image.

Matrix: cp310, cp311, cp312-abi3 (covers 3.12-3.14) - upstream's own [tool.cibuildwheel] matrix, left untouched; upstream ships no cp314t.

Testing

  • same as upstream

License: Wrapper is MIT; the vendored TetGen core is AGPL-3.0 (dual-licensed, commercial option from WIAS) - already declared via upstream's own PEP 639 license-files, unmodified.

Built on cp310/cp311/cp312-abi3; tested via upstream's own pytest {project}/tests.

Python bindings (scikit-build-core + nanobind, abi3 cp312+) over PyVista's
vendored copy of Hang Si's TetGen C++ core. Pure portable C++17, no OpenMP,
no GMP, no other native deps - CMakeLists.txt has OpenMP commented out and
the TetGen/predicates sources are architecture-agnostic. Mirrors the already-
published pymeshfix port (same ecosystem/build shape): single cibuildwheel
job on manylinux_riscv64, upstream's own [tool.cibuildwheel] build matrix
(cp310, cp311, cp312-abi3 covering 3.12-3.14) left untouched, same riscv64
Linux-only env overrides.

Licensing verified directly from the v0.8.4 source: the wrapper's own
LICENSE is MIT (matches pyproject.toml's license = "MIT"), but the vendored
TetGen core (src/tetgen.cxx, src/tetgen.h) is dual-licensed under AGPL-3.0
(with a commercial alternative from WIAS) - captured in src/tetgen-license,
which pyproject.toml's PEP 639 license-files already lists alongside LICENSE,
so both land in the wheel's dist-info/licenses/ unmodified from upstream
(checked for in the build step). No gpl_sources job needed: nothing here is
linked from the manylinux_riscv64 build image's own GPL toolchain (gcc), only
from the project's own already-license-declared sources.

No local build check: no docker daemon available in this sandbox.
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 commented Oct 14, 2026

Copy link
Copy Markdown
Member Author

The failing check (Build tetgen 0.8.4 manylinux_riscv64) fails at the test-dependency install step:

ERROR: Could not find a version that satisfies the requirement pymeshfix (from versions: none)

Not this PR's fault, and not the registry-staleness issue seen elsewhere (torchrl#3067): the tetgen build itself succeeds completely (wheel built, repaired, installed). The real cause is that this port's own pymeshfix build (already published under PR #2551) only ever produced a cp312-abi3 wheel — its CIBW_BUILD was "cp312-* cp313-* cp314-*", which collapses all three into the one abi3 wheel and never built the cp310/cp311 wheels upstream's own build matrix ("cp310-* cp311-* cp312-*") actually ships. This PR builds/tests on cp310 per upstream's own matrix too, so there's simply no compatible pymeshfix wheel in the index for that interpreter.

Fix is up at #3222 (adjusts pymeshfix's build matrix to match upstream exactly). Once merged, I'll trigger a rebuild to publish the missing cp310/cp311 wheels, which should unblock this PR's test step on re-run.


Generated by Claude Code

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