> This is usually solved outside of autopkgtest itself.
>
> For example Ruby packages have a single place where tests are specified
> (debian/ruby-tests.*{rb,rake,yaml}, and the appropriate
> debian/tests/control file is autogenerated by autodep8. I would say 99%
> of Ruby packages require no duplication, or even explicitly specifying
> commands to run tests at all.
>
> In general, this is most efficiently solved by package type (e.g.
> programming language), because the way the tests are run at build-time
> usually is tied to the build system. You then usually need some test
> runner, probably extracted from, or provided by, the build system, to
> also provide the same funcionality in an autopkgtest-compatible way.
>
> All the package types that are well supported in autodep8 have their
> specialized test runner tools that avoid this type of duplication.I'm mostly interested in the python ecosystem, and the provided autodep8 test are extremely superficial (essentially only importing the main python module packaged), which is better than nothing but not the same level as what's in d/rules. Are you aware of any effort to expand the Python autodep8 tests to uniform them into a comprehensive, and unique place to run tests at build-time and via autopkgtest? If no such effort currently exists, what would one have to do to start developing it? Not necessarily volunteering, just gathering information. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
