Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: python <python@g.o>
Subject: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?)
Date: Wed, 04 Mar 2020 12:07:52
Message-Id: 4d8d3412ceb873a63893a488ed52fa329e4a251c.camel@gentoo.org
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?) "Haelwenn (lanodan) Monnier" <contact@×××××××××.me>