On Wed, Jul 31, 2024 at 09:46:27AM +0100, Simon McVittie wrote: > > > My use case, is to check that all the Dependencies computer by dh_python3 from the build tools are indeed listed in the Depends of the binary package. > > > > Maybe we indeed want a "minimal" autopkgtest environment > > For a simple smoke-test that the Python packages import succesfully, isn't > this exactly autopkgtest-pkg-python? Yes. > For thorough test coverage, I don't think this is possible: in general, > the test suite will legitimately require installation of packages that are > only needed during testing (pytest or similar), or packages that are > optional for basic use of the code but mandatory for full test coverage > (those might be Recommends or Suggests). I was thinking about "running a subset of the test suite that doesn't need those optional deps" (I didn't consider that this needs pytest and likely various pytest plugins and their deps so it isn't strictly minimal) and automatically identifying this subset is what I later said I think isn't possible. > > > but many > > upstream tests will fail in those and I don't see an automatic way to test > > a random package in this way > > If we want to run upstream test-suites as autopkgtests, then I think > ideally we want the same test coverage as autopkgtest-pkg-python, > *and* the same test coverage as autopkgtest-pkg-pybuild, as separate > autopkgtest test-cases with different dependencies. I always thought the smoke test is redundant if there is the upstream tests one. What do you think? > But I don't think we can easily have that, because the Testsuite field > only takes one value. It was easy (and achieved by accident) before autopkgtest-pkg-pybuild: you could have upstream tests in debian/tests and the smoke test via Testsuite or automatic discovery (I could never remember which combination gives you both). But, again, I never thought this is desirable and was removing the smoke test. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature