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

[Diego M. Rodriguez]

Hello Andreas,

> 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 see your point, although I was actually not suggesting to skip the
tests entirely at build time, but rather to move their execution from
pybuild to another dh stage, with the reasoning being that "as long as
the tests are executed, there is some leeway in deciding which tool
invokes them".

Perhaps running "pybuild ... --disable test/python3" within
override_dh_auto_build, and then relying on the main makefile to
actually perform tests/swig_python.sh during dh_auto_test would be an
option? I haven't tried that approach yet, and some mangling would
probably be needed to make dh_auto_test aware that the python extension
is available and compiled, but might be doable and have the benefit that
(hopefully) all the tests would be run.

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

I have tried using the "--pattern" argument to unittest discover [1] to
exclude the problematic test_mer_file.py file, as in:
export PYBUILD_TEST_ARGS=${CURDIR}/swig/python/test_string_mers.py -p "test_[!m]*.py"

but unfortunately ran into another problem: it seems the test results
depends on the order they are run:

$ python3 -m unittest test_hash_counter.py test_string_mers.py 
..F.
======================================================================
FAIL: test_all_mers (test_string_mers.TestStringMers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/x/test_string_mers.py", line 21, in test_all_mers
    self.assertTrue(good)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 4 tests in 0.048s

FAILED (failures=1)

$ python3 -m unittest test_string_mers.py test_hash_counter.py 
....
----------------------------------------------------------------------
Ran 4 tests in 0.049s

OK


I'm still not familiar with jellyfish, but I'm guessing that this is
by design and the library shares some "global" state of sorts (which the
current python test suite has been designed around)? 

To work around this issue, I'm including a patch that runs the tests
individually using pybuild (and performs the rpath modification
mentioned on #15 - its only purpose is making libjellyfish-2.0.so
available during the tests, there might be a better way of achieving
it). It should work, but I'm not really happy with the solution and
would be more than willing to help trying to find a better approach if
needed.

Best regards, and thanks a lot for taking the time to look into the
issue,

[1] https://docs.python.org/3/library/unittest.html#cmdoption-unittest-discover-p
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232

-------------- next part --------------
A non-text attachment was scrubbed...
Name: temporary-rpath-and-run-tests-individually.patch
Type: text/x-diff
Size: 1096 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160328/c7b83c02/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160328/c7b83c02/attachment-0003.sig>