Open onitake opened 1 month ago
Does https://github.com/mikedh/trimesh/pull/2298 help at all? PR's welcome! One thing that might help breaking this in the future is if we added a test that tried the debian build, which I have no idea how to do but am open to PR's on 😄.
I don't think there should be a Debian-specific test, but rather some better logic to select and test different engines. For example, there is currently no automatic fallback to the blender engine when manifold3d isn't available, or vice-versa. The rationale is that manifold3d is not a mandatory dependency of trimesh, so it shouldn't cause code to fail. Neither is Blender, of course. Boolean operations should only fail if no engine is available.
The unit tests should also run all tests against all engines and fail when an engine isn't available. In the Debian scripts, we can then simply add a small patch that removes manifold3d from the engine list in the test.
I'll try to come up with a PR based on the idea of selecting an engine globally on module load, with the option of changing the detected default later or passing it to each operation (as it's implemented now).
The Debian build system requires that all dependencies must be available in the Debian ecosystem.
It looked like trimesh wasn't testing with blender at all (good catch!) so I was trying to add it to our docker images which use a Debian trixie
base image. It looked like blender was either removed, or isn't pushed yet for trixie?
Yes, it's unfortunate, but it got kicked out automatically because some dependencies fail to build with other updated dependencies. It's a real mess lately... not least thanks to lots of changes/deprecations in Python 3.12 and 3.13.
You can see the status here: https://tracker.debian.org/pkg/blender
I recommend pulling the latest version from sid instead, that's what I usually do in these situations.
No worries, I installed from a blender tarball. Let me know if https://github.com/mikedh/trimesh/pull/2312 needs some follow-ups on this issue.
Some of the unit tests have been set up so they execute with all available boolean mesh operation engines, but some of them require the default manifold3d engine.
The Debian build system requires that all dependencies must be available in the Debian ecosystem, but we haven't packaged manifold3d yet and need to run all unit tests against the blender engine for now.
Example error:
Aside from test_multiple_difference, these tests would also need modifications: test_boolean_manifold, test_boolean_manifold, test_reduce_cascade
Maybe it would be a better idea to use a test fixture instead, so all unit tests are always run with all engines? Or perhaps there should be a way to set the engine globally and autodetect available engines on module load.