Hi Julian (2024.09.08_21:33:49_+0000)

I built 6440 packages build-depending on dh-python in one way or
another. 1483 failed, and 1124 of them say "NO TESTS RAN" in the logs.

My guess is that most of these 1124 have no tests at all, rather than
having a misconfigured setup. A unittest is the pybuild default test framework, unittest is used and fails to find any tests, hence all of
these failures.

Yes, almost certainly.

4. We could make this failure opt-in in dh-python. Maybe via an explicit
--test-unittest option that selects the unittest runner. If you don't
explicitly select this runner, you'd get an attempt to run tests by
with unittest, and no failure if no tests are found.

I like option 4 for the above reason. But implementing this would
mean that all of the packages that currently *do* use unittest (intentionally, but without having to code it explicitly as it's the
default) would suddenly not have any tests running until they
proactively add --test-unittest or set PYBUILD_TEST_UNITTEST = 1 or
similar. This seems like an unfortunate consequence.

I would leave unittest as the default runner, but without missing test detection.

That's a slightly unexpected behaviour, but it makes the default case
work.

Downside is that you have to opt-in to missing test detection. Maybe we
can have a lintian tag for that?

Stefano

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandre (2024.09.12_14:26:13_+0000)

From my personal experience, the most common cause of missing tests

is because d/watch follow pypi where the tarball is incomplete
and the typical fix is to switch to github tarball.

Could this "1139 NO TESTS RAN" correlated with d/watch ?

It'll be part of them, yes.

Stefano

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-08 13:21, Scott Kitterman wrote:

Thanks. I think some variation of #4 is the right answer. Causing a thousand packages to FTBFS isn't great. I would find it easier to have an environment variable (similar to what you suggested for #3) instead of adding an override, but that's more

of an implementation detail.

Scott K

Having an opt-in environment variable means all the packages using
unittest will eventually need to add it.

What is the end goal? Once we have enough buy-in we flip it around?

I agree breaking tons of packages isn't great, but I don't want us to
haul crud forever either :(

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)