On Feb 04, 2016, at 09:08 PM, Sean Whitton wrote: >I'm packaging a Python application, ocrmypdf [1], that has a test suite >run by py.test. Most of the tests fail because they try to call the >/usr/bin/ocrmypdf script. This script doesn't exist until after >debhelper has run setup.py, which generates it using its "entry points >script" feature. And this comes after dh_auto_test. > >The only solution I've come up with is producing my own entry point >script and putting it into $PATH for the test suite to use. But that >rather defeats the purpose of testing the actual package's contents. There are a few approaches I've taken in similar situations. If ocrmypdf supports Python's -m option, you could consider patching the test suite to run `python -m ocrmydf` instead. Season to taste for python3 and or both if you're using pybuild. If the package uses tox to run its test suite, then you'll have the executable in .tox/pyXY/bin and you could try to run that instead. As a last resort, I have disabled the build-time tests (all or only the ones that require the /usr/bin) and then arranged for the full test suite to run via autopkgtest/DEP-8. It's not ideal because Debian currently doesn't gate on DEP-8 passing, but Ubuntu does and at least I'll see failures there. FWIW, I think it's almost always a good idea to add a simple DEP-8 smoke test for Python packages, just to prove that the modules can be imported if nothing else. Cheers, -Barry
Attachment:
pgplJXRppRhAJ.pgp
Description: OpenPGP digital signature