On Mar 01, 2016, at 06:10 PM, Martin Pitt wrote: >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).
Ah cool, this is what I didn't understand from reading the README. I was sort of looking for the equivalent of README.package-tests.rst, i.e. what do I have to do to my packages to opt-in to autodep8? Or on the flip side, what do we need to do globally to just enable it for all packages (where "all" == 80/20 of course :). >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. One of the problems is the wide variety of ways for invoking a package's test suite in Python. I've been pushing at those edges for a long time. Ideally I think the packaging metadata specs should define that, and it's on their radar, just not any time soon. My personal favorite is to look for a tox.ini file and then just invoke `tox` but there are a few upstream features I still want to make that really work nicely. (Still, I encourage all upstream Python authors to look closely at tox, it pretty much rules. :) pybuild has a bunch of heuristics for trying to figure out how to invoke a package's test suite, so that could be code/ideas that we could steal or share. >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. Yep. I think that's clearly the first step. Cheers, -Barry
pgpa5fEUGQypS.pgp
Description: OpenPGP digital signature
