| 1 |
On Sun, 2023-02-19 at 18:32 +0100, Michał Górny wrote: |
| 2 |
> +Abstract |
| 3 |
> +======== |
| 4 |
> + |
| 5 |
> +A new ``TEST_SUITE_PRESENT`` variable is introduced to indicate whether |
| 6 |
> +the package features a test suite. It can be set either by the ebuild, |
| 7 |
> +the eclass or the default ``src_test`` implementation, and afterwards |
| 8 |
> +included in the package manager logs. This can aid in analyzing |
| 9 |
> +the results of automated package testing. |
| 10 |
> |
| 11 |
|
| 12 |
I've decided to withdraw this proposal. After giving it more thought, |
| 13 |
it doesn't really solve the problem it was intended to solve, and it is |
| 14 |
unnecessarily complex for a non-solution. |
| 15 |
|
| 16 |
Long story short, a package may use Python AND have a test suite, yet |
| 17 |
not test anything actually written in Python. The proposal would |
| 18 |
qualify these packages as having the test suite, yet in the end it |
| 19 |
wouldn't provide useful input for PYTHON_COMPAT testing. |
| 20 |
|
| 21 |
I think a domain-specific solution such as checking for python_test() or |
| 22 |
distutils_enable_tests will work better here, and other packages will |
| 23 |
still require manual verification. |
| 24 |
|
| 25 |
-- |
| 26 |
Best regards, |
| 27 |
Michał Górny |
Archives