[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: q2-sample-classifier



If I may suggest,
(Taking the liberty do so, feel free to ignore this e-mail if you don't find these good)

As is, the build time test suite was choking on py.test, so I
begun working on a small patch against the Makefile to rename
this py.test-3 and build depend on "python3-pytest <!nocheck>".

Rather than patching the Makefile, you could simply --with python3 --buildsystem=pybuild

This saves us from un-necessary delta with upstream.

However when adding a few more test dependencies[1], I hit that
wall, where registration of the q2 modules seems to be expected:

           dh_auto_test
                make -j6 test
        make[1]: Entering directory '/<<PKGBUILDDIR>>'
        py.test-3
        ============================= test session starts ==============================
        platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
        rootdir: /<<PKGBUILDDIR>>
        collected 0 items / 6 errors

        ==================================== ERRORS ====================================
        _________ ERROR collecting q2_sample_classifier/tests/test_actions.py __________
        ImportError while importing test module '/<<PKGBUILDDIR>>/q2_sample_classifier/tests/test_actions.py'.
        Hint: make sure your test modules/packages have valid Python names.
        Traceback:
        q2_sample_classifier/tests/test_actions.py:13: in <module>
            from qiime2.plugins import sample_classifier
        E   ImportError: cannot import name 'sample_classifier' from 'qiime2.plugins' (/usr/lib/python3/dist-packages/qiime2/plugins.py)

[1] namely build time test dependencies are : python3-distutils,
    q2-types and qiime.

Maybe the debian/rules will need an:

        override_dh_auto_test:
        # FIXME: test delayed to autopkgtest

and the package will need an autopkgtest which executes
py.test-3 on the installed module distribution, a bit similar to
what qiime and q2-types are doing at the moment?

Yes, final agenda is to execute pytest and see if it works well or not.
Hence disabling build-time test and executing pytest is good.

I've seen other packages under med-team as well which do the same thing - because build-time tests are not run-able w/o package installation.


I didn't have anything to push, I'm not sure how you would wish
to move forward on this one.

> Many thanks,
>
> Steffen (hoping ITPs also count for the calendar)
>
> We should actually think of some Xmas / New Year Promises packaging
> story, like comparing the microbiome of the present, the past and the
> future. The age-effect comparing with the past is obvious (drinking
> mostly milk, parental priming in the very early days). That "future"
> thingy is more real than what the wider public is yet aware of, for one
> there is our immune system that is changing, but there is also
> nutritional genomics so we are not completely out of control.  Anybody
> feeling creative?

Sounds interesting, but I'm not sure I understood your idea?  :)

+1 :-P

Reply to: