1 |
Signed-off-by: Michał Górny <mgorny@g.o> |
2 |
--- |
3 |
glep-9999.ebuild | 132 +++++++++++++++++++++++++++++++++++++++++++++++ |
4 |
1 file changed, 132 insertions(+) |
5 |
create mode 100644 glep-9999.ebuild |
6 |
|
7 |
diff --git a/glep-9999.ebuild b/glep-9999.ebuild |
8 |
new file mode 100644 |
9 |
index 0000000..9ee18ca |
10 |
--- /dev/null |
11 |
+++ b/glep-9999.ebuild |
12 |
@@ -0,0 +1,132 @@ |
13 |
+--- |
14 |
+GLEP: 9999 |
15 |
+Title: TEST_SUITE_PRESENT variable |
16 |
+Author: Michał Górny <mgorny@g.o> |
17 |
+Type: Standards Track |
18 |
+Status: Draft |
19 |
+Version: 1 |
20 |
+Created: 2023-02-19 |
21 |
+Last-Modified: 2023-02-19 |
22 |
+Post-History: 2023-02-19 |
23 |
+Content-Type: text/x-rst |
24 |
+--- |
25 |
+ |
26 |
+ |
27 |
+Abstract |
28 |
+======== |
29 |
+ |
30 |
+A new ``TEST_SUITE_PRESENT`` variable is introduced to indicate whether |
31 |
+the package features a test suite. It can be set either by the ebuild, |
32 |
+the eclass or the default ``src_test`` implementation, and afterwards |
33 |
+included in the package manager logs. This can aid in analyzing |
34 |
+the results of automated package testing. |
35 |
+ |
36 |
+ |
37 |
+Motivation |
38 |
+========== |
39 |
+ |
40 |
+The deployment of new Python targets in Gentoo currently involves |
41 |
+testing of a large number of Gentoo packages against the said target. |
42 |
+This is currently done manually for the most part. It can be |
43 |
+particularly time consuming if multiple individuals repeatedly test |
44 |
+the same package only to determine that it remains incompatible with |
45 |
+the new interpreter. |
46 |
+ |
47 |
+The Python team wanted to explore the use of automation to aid this |
48 |
+testing. Unfortunately, this faces a major problem: for the vast |
49 |
+of majority of packages, the incompatibilities with new Python versions |
50 |
+do not exhibit during the installation and can only be detected through |
51 |
+running the test suite. The results of automated testing are therefore |
52 |
+only meaningful if the package features a test phase. |
53 |
+ |
54 |
+For packages using ``distutils-r1`` eclass, the presence of test suite |
55 |
+can usually be easily determined through grepping for |
56 |
+``distutils_enable_tests`` call or an explicit ``python_test()`` |
57 |
+function. Even then, it seems sensible to work towards a more generic |
58 |
+approach to tell whether a package had a test suite or not, |
59 |
+and therefore whether a particular successful automated testing result |
60 |
+means that the package actually passed tests or only confirmed that |
61 |
+the Python files were copied successfully. |
62 |
+ |
63 |
+An explicit indication whether a test suite was present can be presented |
64 |
+by the package manager as part of logs, along with the result of running |
65 |
+the test phase. Afterwards, these logs can be used to determine which |
66 |
+packages were actually tested. |
67 |
+ |
68 |
+ |
69 |
+Specification |
70 |
+============= |
71 |
+ |
72 |
+A new ``TEST_SUITE_PRESENT`` variable is introduced that can be set |
73 |
+by a ``src_test()`` implementation to indicate whether the package |
74 |
+featured a test suite. It can take three values: |
75 |
+ |
76 |
+- ``yes`` indicating that a test suite was run |
77 |
+- ``indeterminate`` indicating that it was not possible to clearly |
78 |
+ determine whether the test suite was present or not (this could be |
79 |
+ a case e.g. when a generic test command is run and it does not |
80 |
+ indicate whether any tests were found) |
81 |
+- ``no`` indicating that no test suite was run |
82 |
+ |
83 |
+This variable *should* be set by eclasses defining the ``src_test()`` |
84 |
+phase. If the package in question is using ``src_test()`` defined |
85 |
+by an eclass that does not declare it explicitly, the PM must assume |
86 |
+``indeterminate``. |
87 |
+ |
88 |
+The variable *may* be set by an ebuild defining the ``src_test()`` |
89 |
+phase. If the ebuild does not define it explicitly, the PM must assume |
90 |
+``yes``. |
91 |
+ |
92 |
+The default ``src_test()`` implementation as defined by the PMS sets |
93 |
+the value to ``indeterminate`` if it runs a ``check`` or ``test`` |
94 |
+target, and to ``no`` if neither of the targets is found. |
95 |
+ |
96 |
+ |
97 |
+Rationale |
98 |
+========= |
99 |
+ |
100 |
+The use of ternary flag makes it possible to clearly represent all three |
101 |
+possible outcomes while navigating the defaults defined in the GLEP. |
102 |
+The flag is set in ``src_test()``, so that runtime conditions (such |
103 |
+as the results obtained from the actual test runner) can be used to |
104 |
+determine the actual value. |
105 |
+ |
106 |
+The defaults were defined based on the following assumptions: |
107 |
+ |
108 |
+1. The presence of ``check`` target is common in autotools projects but |
109 |
+ it does not guarantee that the target actually does anything, let |
110 |
+ alone run a proper test suite. However, the lack of any test target |
111 |
+ clearly indicates that no tests were run. |
112 |
+ |
113 |
+2. Eclass ``src_test`` implementations can be very generic and succeed |
114 |
+ without actually performing any testing. It is therefore reasonable |
115 |
+ to default to ``indeterminate`` result when they are used, |
116 |
+ and recommend them to explicitly override the variable. |
117 |
+ |
118 |
+3. Explicit ``src_test`` declared in ebuild can generally be assumed |
119 |
+ to actually run tests, with the exception of declaring the function |
120 |
+ to prevent ``default_src_test`` from running. It therefore makes |
121 |
+ sense to default to ``yes`` but allow ebuilds to override the value |
122 |
+ in the latter case. |
123 |
+ |
124 |
+ |
125 |
+Backwards Compatibility |
126 |
+======================= |
127 |
+ |
128 |
+This GLEP is entirely optional. The package managers not implementing |
129 |
+it will treat the variable as a regular bash variable set by the test |
130 |
+phase and ignore it. |
131 |
+ |
132 |
+ |
133 |
+Reference Implementation |
134 |
+======================== |
135 |
+ |
136 |
+TODO |
137 |
+ |
138 |
+ |
139 |
+Copyright |
140 |
+========= |
141 |
+ |
142 |
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 |
143 |
+International License. To view a copy of this license, visit |
144 |
+https://creativecommons.org/licenses/by-sa/4.0/. |
145 |
-- |
146 |
2.39.2 |