pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)

[Julian Gilbey <julian@d-and-j.net>]

On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Véronneau wrote:
> == pybuild improvements ==
> 
> getting the autopkgtest MR in would be great
> 
> https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
> 
> We need people to test this MR some more, although it seems fairly mature.
> 
> It might be a good idea to have a line in d/control to let us migrate from
> the existing autopkgtests running unit tests to the new automated MR.

I've been looking at this a bit more.  I'm not sure what this last
paragraph means: the new "automated" autopkgtest will only be run if
the maintainer explicitly adds:

Testsuite: autopkgtest-pkg-pybuild

to debian/control (see the autodep8 MR at
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs -
it will never automatically detect a pybuild package).
And a maintainer would presumably only add that if they are also
removing their existing debian/tests/control (or want to run the
pybuild tests in addition).

An alternative would be for the autodep8 patch to try to determine
whether to run pybuild-autopkgtest.  One approach could be:

if the package would run autopkgtest-pkg-python:
  if debian/control does not contain an override_dh_auto_test stanza:
    run pybuild-autopkgtest

Note, though, that if autodep8 is called, it will run all of the
detected tests.  (At least that is what I believe happens from reading
/usr/bin/autodep8; I haven't double-checked this.)  So, for example,
if a package specifies

Testsuite: autopkgtest-pkg-python

it will also run the autopkgtest-pkg-pybuild suite as it will be
detected as being a Python package, and vice versa.  That is a
possible reason *not* to use the above suggestion, as it would
potentially run pybuild-autopkgtest even if not desired.

Best wishes,

   Julian