1 |
Hi, everyone. |
2 |
|
3 |
After sending the recent proposal for python-r2 eclass suite, I've |
4 |
realized that I have ended up somewhere in the middle of two possible |
5 |
goals. Therefore, I'd like to take a step back and ask what kind of |
6 |
python-r2 suite would be preferable. |
7 |
|
8 |
I see two basic options: either we go for removing deprecated API while |
9 |
keeping the changes to the bare minimum possible without runtime |
10 |
testing, or we go for changing some more and require runtime testing |
11 |
when porting. Let me expand on both concepts. |
12 |
|
13 |
|
14 |
Approach A: minimal API changes |
15 |
=============================== |
16 |
In this approach, I make only clearly cut API changes. It will be |
17 |
possible to migrate most of the ebuilds via a bunch of seds in a script, |
18 |
and to detect cases needing manual update via some more greps. This |
19 |
will make the migration quick and mostly painless. |
20 |
|
21 |
As an implication of that, I would keep support for all old EAPIs |
22 |
and not make any of the runtime warnings more fatal than they are right |
23 |
now (particularly DISTUTILS_USE_SETUPTOOLS remains a warning). |
24 |
|
25 |
The migration plan would be roughly to: |
26 |
|
27 |
1. Prepare a script converting ebuilds to new eclasses. |
28 |
|
29 |
2. Run a test conversion and pass it over to Toralf for random testing. |
30 |
|
31 |
3. Push the conversion. |
32 |
|
33 |
4. Deprecate the old eclasses. |
34 |
|
35 |
5. Convert remaining ebuilds manually (those that script can't convert). |
36 |
|
37 |
6. Last rite the old eclasses. |
38 |
|
39 |
|
40 |
Approach B: maximum cleanup |
41 |
=========================== |
42 |
This approach involves making all current warnings fatal, and removing |
43 |
support for old EAPIs. While script would still help updating ebuilds, |
44 |
it will be necessary to test every migrated ebuild. |
45 |
|
46 |
The migration plan would be roughly to: |
47 |
|
48 |
1. Prepare the script. |
49 |
|
50 |
2. Convert some ebuilds on bumps. |
51 |
|
52 |
3. Deprecate the old eclasses. |
53 |
|
54 |
4. Wait forever for ::gentoo to be converted. |
55 |
|
56 |
5. Last rite the old eclasses. |
57 |
|
58 |
6. Wait again. |
59 |
|
60 |
7. Remove the eclasses and hear people complaining that 6.5 years were |
61 |
too short to migrate over. |
62 |
|
63 |
|
64 |
Approach C: hybrid approach |
65 |
=========================== |
66 |
Alternatively, I could combine both approaches: commit python-r2 suite |
67 |
that follows approach A, and python-r3 suite that follows B. For |
68 |
practical reasons, the -r3 eclasses would probably boil down to: |
69 |
|
70 |
_PYTHON_R3_API=1 |
71 |
inherit python...-r2 |
72 |
|
73 |
as they would merely enforce stricter warning rules. |
74 |
|
75 |
The migration plan: |
76 |
|
77 |
1. Prepare the script. |
78 |
|
79 |
2. Run a test conversion to -r2, ask Toralf, push it. |
80 |
|
81 |
3. In parallel, start manually switching to -r3 on bumps. |
82 |
|
83 |
4. Deprecate -r1 and -r2. |
84 |
|
85 |
5. Convert remaining ebuilds from -r1 to -r3. |
86 |
|
87 |
6. Last rite -r1. |
88 |
|
89 |
7. Wait forever. |
90 |
|
91 |
8. Last rite -r2. |
92 |
|
93 |
|
94 |
Summary |
95 |
======= |
96 |
So to summarize, of the three proposed approaches: |
97 |
|
98 |
1. A & C provide for fast cleanup of old API with mostly-automated |
99 |
conversion. |
100 |
|
101 |
2. B & C provide for gradual cleanup of warnings and old EAPIs, i.e. |
102 |
stuff requiring runtime testing. |
103 |
|
104 |
3. A & C makes it possible to get rid of -r1 shortly and reduce |
105 |
maintenance effort. |
106 |
|
107 |
|
108 |
What do you think? |
109 |
|
110 |
|
111 |
-- |
112 |
Best regards, |
113 |
Michał Górny |