Stuart Prescott <[email protected]> writes: > Telling autopkgtest to run the tests against the module as installed > is enough; the following works both at build time and at autopkgtest > time: > > export PYBUILD_TEST_ARGS = --pyargs jaraco.logging
Thanks; that is a command-line option for PyTest that instructs it to import modules and find test cases on them. Okay, that allows removing entirely the custom test suite for AutoPkgTest, and allowing it to run just PyTest as specified. > - PYBUILD_AFTER_TEST is unnecessary now that you don't have the manual > d/*install step, so you can lose a few lines from d/rules. Done, thank you. Is this because PyBuild (or something else?) does the cleanup of PyTest temporary cruft? > - PYBUILD_SYSTEM is unneeded because that is explicitly what the build > dependency on pybuild-plugin-pyproject asks for already. The ‘dh’ option ‘--buildsystem pybuild’ also specifies this. Is that what instructs PyBuild correctly? Or is that option also superfluous? > - PYBUILD_INSTALL_ARGS is unneeded (it does nothing in pybuild's > pyproject-based workflow) Because the ‘pyproject’ build system (instructing it to use a PEP %!& + PEP 518 build system interface) causes PyBuild to ignore the ‘--install-args’ option? > - --test-pytest is unneeded as the explicit build-dep on > python3-pytest means the same thing So, if hypothetically another source package needs to declare “Build-Depends: python3-pytest”, but *not* the ‘--test-pytest’ behaviour, what then? We need an explicit ‘--test-custom’ or the like? > - oldoldstable also satisfies the version constraint for > python3-pytest, so unless you are particularly keen on porting to > some ancient LTS (that won't have a new enough python3 for this > package anyway), you can skip that too. Done, thank you. (I had attempted to specify the complex dependency from upstream, “pytest >= 6, != 8.1.*”. But it was too much trouble translating that to Debian dependency relationships, and anyway no Debian release has any of the problematic PyTest versions.) > Obviously none of these things are important…, but deleting things now > might save a future someone wondering why they were added or prevent > them propagating into other packages via copy+paste. It also inches us > towards declarative packaging by having much less in d/rules. I'm definitely in favour of this. I just wish the facts of Python packaging in Debian were better kept up to date, maybe in the wiki, and not reliant on stumbling to error and knowledge locked away in people's minds. There's a lot of outdated advice written out there. -- \ “Never do anything against conscience even if the state demands | `\ it.” —Albert Einstein | _o__) | Ben Finney
