Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8194 > unrolled thread

Test suite needs script built after dh_auto_test is run

Back to article view | Back to linux.debian.maint.python

Contents

  Test suite needs script built after dh_auto_test is run Sean Whitton <spwhitton@spwhitton.name> - 2016-02-05 05:10 +0100
    Re: Test suite needs script built after dh_auto_test is run Barry Warsaw <barry@python.org> - 2016-02-05 20:20 +0100
      Re: Test suite needs script built after dh_auto_test is run Sean Whitton <spwhitton@spwhitton.name> - 2016-02-07 00:20 +0100

#8194 — Test suite needs script built after dh_auto_test is run

[Multipart message — attachments visible in raw view] — view raw

Hello,

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.

What would be the most elegant way to handle this?  Can anyone point me
to a package that had a similar issue with the test suite needing a file
not yet generated?

Thanks.

[1] https://github.com/jbarlow83/OCRmyPDF

-- 
Sean Whitton

[toc] | [next] | [standalone]

#8195

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#8197

[Multipart message — attachments visible in raw view] — view raw

Dear Barry,

On Fri, Feb 05, 2016 at 02:17:51PM -0500, Barry Warsaw wrote:
> 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.
> 
> [snip]
> 
> 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.

Thank you for your input: that worked, aside from one test that wanted
to pass Unicode on the command line which the `python -m ocrmypdf`
method doesn't like.  I commented that one out and have got the full
test suite running with autopkgtest.

I've submitted a request to join the Python Apps Packaging Team so that
I can request sponsorship for my package.

-- 
Sean Whitton

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web