Hey Barry, Barry Warsaw [2016-03-01 10:48 -0500]: > I gather that it's supposed to be used by the maintainer in a source package > ($vcs repo) to jumpstart a debian/tests directory? You could use it for that purpose indeed, but that's not really what it is intended for. The idea is that the generic tests apply to all packages of a particular type, so you can change them centrally instead of having to modify and upload hundreds of packages. There is one more thing, though: The test machinery needs to be able to discover that a package has an autodep8 test (without having the source package already available, as getting and checking that is very expensive). So ideally all source packages which want to use that will get a "Testsuite: autopkgtest-pkg-python" header in debian/control, like for example libnet-oauth-perl. However, until these get uploaded we can add some custom code to debci to recognize those packages based on the name and dependencies (that's what we did for bootstrapping the perl and ruby autodep8 tests). > I'm not sure how useful things like "setup.py test" are for DEP-8. In general > I think a package's test suite are best exercised during package build[*]. During package build is of course good, but one of the points of autopkgtest is to run the tests when one of your dependencies change (and thus potentially break you). > For the majority of Python packages, I view DEP-8 as ensuring that the user > experience is what they expect, and that means at a minimum that the packages > import and Do Something Simple. A generic proof of non-broken import can mean > printing the package's version or the module path, and that's something that > autopkg8 could templatize. Anything more than that requires some more > detailed knowledge about what the package does. As I said, running upstream tests works surprisingly well for Perl/Ruby, we had about 80% success rate. But they are a bit more rigid in structure apparently. But indeed, ensuring that your module still imports already says a lot. New dependencies can still break your module in subtle ways, but at least things like new/removed Python versions, linker errors, wrong paths etc. are spotted. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: PGP signature