autodep8 has two modes for testing Python modules:
1. "Testsuite: autopkgtest-pkg-python" generates a simple smoke-test:
install python3-foo and its mandatory dependencies, run 'import foo'
and assert that it succeeds.
2. "Testsuite: autopkgtest-pkg-pybuild" generates a more elaborate
test: install python3-foo and also the build-dependencies of the source
package, and attempt to run the upstream test suite against the
installed python3-foo.
This must install the full build-dependencies, because in general the
upstream test suite will require additional packages beyond the
mandatory dependencies of python3-foo: either test infrastructure like
pytest, or dependencies of optional features. For example python3-tap
`Recommends: python3-more-itertools, python3-yaml`, but does not depend
on them, because they are only needed for some (rare) features; but
running the upstream test suite *requires* those extra modules.
The Python team is discussing making (2.) mandatory, or at least strongly
recommended. However, for packages that are already using (1.), this loses
some test coverage: we would no longer be verifying that the package's
mandatory dependencies are enough to import it!
Ideally we would have a way to do (1.) *and* (2.). Perhaps
Testsuite: autopkgtest-pkg-pybuild could generate both tests, either always
or with some mechanism to opt-in?
A workaround is to handle one of (1.) or (2.) automatically, and hard-code
the test that would be generated by the other one into debian/tests/control
(but that seems undesirable, because the whole point of autodep8 is to be
able to change these generated test definitions centrally without having to
re-upload every package).
smcv