After some more testing, I'm wondering if it would be sensible to just *not* aim for having the python tests run during pybuild, and instead stick to running them on a separate stage (or during autopkgtest, which I have not ventured into yet). The main reason is that one of the tests (swig/python/test_mer_file.py) seems not really be meant to be executed using the standard unittest module, as it relies on a "data" variable created during __main__(), plus some hard-coded references to files generated during tests/swig_python.sh.
I made some attempts to running the tests during pybuild by: * building the extension with rpath, removing it with chrpath --delete right afterwards (kind of negating the "drop-rpath" patch temporarily): export PYBUILD_BUILD_ARGS=build_ext --rpath "${CURDIR}/debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}" ... pybuild ... chrpath --delete ... * patching the tests to provide a valid value for the "data" variable when run via unittest. * using PYBUILD_BEFORE_TEST and PYBUILD_AFTER_TEST to generate the files required by the test and place them in a reachable directory, cleaning up afterwards. While it seems doable (and probably prone to be refined), it feels rather unorthodox and introducing some extra complexity for a seamingly small gain - I'm still not that familiar with the package's build system and specifics, but suspect that there are better ways to tackle this issue, and I'd appreciate some hints or thoughts on the best course of action. Best regards, -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature