[Debian-med-packaging] Bug#819016: jellyfish: Rename python bindings module name

[Andreas Tille]

Hi Diego,

thanks for diving into this.

On Fri, Mar 25, 2016 at 07:09:18PM +0100, Diego M. Rodriguez wrote:
> 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 need to admit I'm in favour of running any test at build time as well
as in an autopkgtest (see Debian Continuous Integration) as far as it is
sensible.  So if it turns out that parts of the test suite can not
sensibly be run under every condition only this part should be excluded.

> 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.

I have not yet found time to dive into python-jellyfish yet so I'm just
saying what I would try to approach:  If it is easily possible to
deactivate this part of the test suite that seems troublesome I would
go for it.

Kind regards

      Andreas.

-- 
http://fam-tille.de