1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
|
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />
<title>Maintenance of Python implementations — Gentoo Python Guide documentation</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css" />
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
<script src="_static/jquery.js"></script>
<script src="_static/underscore.js"></script>
<script src="_static/_sphinx_javascript_frameworks_compat.js"></script>
<script src="_static/doctools.js"></script>
<script src="_static/sphinx_highlight.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="prev" title="Python package maintenance" href="package-maintenance.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="maintenance-of-python-implementations">
<h1>Maintenance of Python implementations<a class="headerlink" href="#maintenance-of-python-implementations" title="Permalink to this heading">¶</a></h1>
<section id="notes-specific-to-python-interpreters">
<h2>Notes specific to Python interpreters<a class="headerlink" href="#notes-specific-to-python-interpreters" title="Permalink to this heading">¶</a></h2>
<section id="cpython-patchsets">
<h3>CPython patchsets<a class="headerlink" href="#cpython-patchsets" title="Permalink to this heading">¶</a></h3>
<p>Gentoo is maintaining patchsets for all CPython versions. These include
some non-upstreamable Gentoo patches and upstream backports. While it
is considered acceptable to add a new patch (e.g. a security bug fix)
to <code class="docutils literal notranslate"><span class="pre">files/</span></code> directory, it should be eventually moved into
the respective patchset.</p>
<p>When adding a new version, it is fine to use an old patchset if it
applies cleanly. If it does not, you should regenerate the patchset
for new version.</p>
<p>The origin for Gentoo patches are the <code class="docutils literal notranslate"><span class="pre">gentoo-*</span></code> tags the <a class="reference external" href="https://gitweb.gentoo.org/fork/cpython.git/">Gentoo fork
of CPython repository</a>. The recommended workflow is to clone
the upstream repository, then add Gentoo fork as a remote, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clone</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">python</span><span class="o">/</span><span class="n">cpython</span>
<span class="n">cd</span> <span class="n">cpython</span>
<span class="n">git</span> <span class="n">remote</span> <span class="n">add</span> <span class="n">gentoo</span> <span class="n">git</span><span class="nd">@git</span><span class="o">.</span><span class="n">gentoo</span><span class="o">.</span><span class="n">org</span><span class="p">:</span><span class="n">fork</span><span class="o">/</span><span class="n">cpython</span><span class="o">.</span><span class="n">git</span>
<span class="n">git</span> <span class="n">fetch</span> <span class="o">--</span><span class="n">tags</span> <span class="n">gentoo</span>
</pre></div>
</div>
<p>In order to rebase the patchset, check out the tag corresponding
to the previous patchset version and rebase it against the upstream
release tag:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="n">gentoo</span><span class="o">-</span><span class="mf">3.7.4</span>
<span class="n">git</span> <span class="n">rebase</span> <span class="n">v3</span><span class="mf">.7.6</span>
</pre></div>
</div>
<p>You may also add additional changes via <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span></code>. Once
the new patches are ready, create the tarball and upload it, then
create the tag and push it:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">mkdir</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span>
<span class="n">cd</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span>
<span class="n">git</span> <span class="nb">format</span><span class="o">-</span><span class="n">patch</span> <span class="n">v3</span><span class="mf">.7.6</span>
<span class="n">cd</span> <span class="o">..</span>
<span class="n">tar</span> <span class="o">-</span><span class="n">cf</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span><span class="o">.</span><span class="n">tar</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span>
<span class="n">xz</span> <span class="o">-</span><span class="mi">9</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span><span class="o">.</span><span class="n">tar</span>
<span class="n">scp</span> <span class="n">python</span><span class="o">-</span><span class="n">gentoo</span><span class="o">-</span><span class="n">patches</span><span class="o">-</span><span class="mf">3.7.6</span><span class="o">.</span><span class="n">tar</span><span class="o">.</span><span class="n">xz</span> <span class="o">...</span>
<span class="n">git</span> <span class="n">tag</span> <span class="n">gentoo</span><span class="o">-</span><span class="mf">3.7.6</span>
<span class="n">git</span> <span class="n">push</span> <span class="o">--</span><span class="n">tags</span> <span class="n">gentoo</span>
</pre></div>
</div>
</section>
<section id="pypy">
<h3>PyPy<a class="headerlink" href="#pypy" title="Permalink to this heading">¶</a></h3>
<p>Due to high resource requirements and long build time, PyPy on Gentoo
is provided both in source and precompiled form. This creates a bit
unusual ebuild structure:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">dev-python/pypy-exe</span></code> provides the PyPy executable and generated
files built from source,</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">dev-python/pypy-exe-bin</span></code> does the same in precompiled binary form,</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">dev-python/pypy</span></code> combines the above with the common files. This
is the package that runs tests and satisfies the PyPy target.</p></li>
</ul>
<p>Matching <code class="docutils literal notranslate"><span class="pre">dev-python/pypy3*</span></code> exist for PyPy3.</p>
<p>When bumping PyPy, <code class="docutils literal notranslate"><span class="pre">pypy-exe</span></code> needs to be updated first. Then it
should be used to build a binary package and bump <code class="docutils literal notranslate"><span class="pre">pypy-exe-bin</span></code>.
Technically, <code class="docutils literal notranslate"><span class="pre">pypy</span></code> can be bumped after <code class="docutils literal notranslate"><span class="pre">pypy-exe</span></code> and used to test
it but it should not be pushed before <code class="docutils literal notranslate"><span class="pre">pypy-exe-bin</span></code> is ready, as it
would force all users to switch to source form implicitly.</p>
<p>The binary packages are built using <a class="reference external" href="https://www.docker.com/">Docker</a> nowadays, using
<a class="reference external" href="https://github.com/mgorny/binpkg-docker">binpkg-docker</a> scripts. To produce them, create a <code class="docutils literal notranslate"><span class="pre">local.diff</span></code>
containing changes related to PyPy bump and run <code class="docutils literal notranslate"><span class="pre">amd64-pypy</span></code>
(and/or <code class="docutils literal notranslate"><span class="pre">amd64-pypy3</span></code>) and <code class="docutils literal notranslate"><span class="pre">x86-pypy</span></code> (and/or <code class="docutils literal notranslate"><span class="pre">x86-pypy3</span></code>) make
targets:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clone</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">mgorny</span><span class="o">/</span><span class="n">binpkg</span><span class="o">-</span><span class="n">docker</span>
<span class="n">cd</span> <span class="n">binpkg</span><span class="o">-</span><span class="n">docker</span>
<span class="p">(</span><span class="n">cd</span> <span class="o">~/</span><span class="n">git</span><span class="o">/</span><span class="n">gentoo</span> <span class="o">&&</span> <span class="n">git</span> <span class="n">diff</span> <span class="n">origin</span><span class="p">)</span> <span class="o">></span> <span class="n">local</span><span class="o">.</span><span class="n">diff</span>
<span class="n">make</span> <span class="n">amd64</span><span class="o">-</span><span class="n">pypy</span> <span class="n">amd64</span><span class="o">-</span><span class="n">pypy3</span> <span class="n">x86</span><span class="o">-</span><span class="n">pypy</span> <span class="n">x86</span><span class="o">-</span><span class="n">pypy3</span>
</pre></div>
</div>
<p>The resulting binary packages will be placed in your home directory,
in <code class="docutils literal notranslate"><span class="pre">~/binpkg/${arch}/pypy</span></code>. Upload them and use them to bump
<code class="docutils literal notranslate"><span class="pre">pypy-exe-bin</span></code>.</p>
</section>
</section>
<section id="adding-a-new-python-implementation">
<h2>Adding a new Python implementation<a class="headerlink" href="#adding-a-new-python-implementation" title="Permalink to this heading">¶</a></h2>
<section id="eclass-and-profile-changes">
<h3>Eclass and profile changes<a class="headerlink" href="#eclass-and-profile-changes" title="Permalink to this heading">¶</a></h3>
<p>When adding a new Python target, please remember to perform all
the following tasks:</p>
<ul class="simple">
<li><p>add the new target flags to <code class="docutils literal notranslate"><span class="pre">profiles/desc/python_targets.desc</span></code>
and <code class="docutils literal notranslate"><span class="pre">python_single_target.desc</span></code>.</p></li>
<li><p>force the new implementation on <code class="docutils literal notranslate"><span class="pre">dev-lang/python-exec</span></code>
via <code class="docutils literal notranslate"><span class="pre">profiles/base/package.use.force</span></code>.</p></li>
<li><p>mask the new target flags on stable profiles
via <code class="docutils literal notranslate"><span class="pre">profiles/base/use.stable.mask</span></code>.</p></li>
<li><p>update <code class="docutils literal notranslate"><span class="pre">python-utils-r1.eclass</span></code>:</p>
<ol class="arabic simple">
<li><p>add the implementation to <code class="docutils literal notranslate"><span class="pre">_PYTHON_ALL_IMPLS</span></code></p></li>
<li><p>update the patterns in <code class="docutils literal notranslate"><span class="pre">_python_verify_patterns</span></code></p></li>
<li><p>update the patterns in <code class="docutils literal notranslate"><span class="pre">_python_set_impls</span></code></p></li>
<li><p>update the patterns in <code class="docutils literal notranslate"><span class="pre">_python_impl_matches</span></code></p></li>
<li><p>add the appropriate dependency to the case for <code class="docutils literal notranslate"><span class="pre">PYTHON_PKG_DEP</span></code></p></li>
</ol>
</li>
<li><p>update the tested version range in <code class="docutils literal notranslate"><span class="pre">eclass/tests/python-utils-r1.sh</span></code></p></li>
<li><p>add the new implementation to the list
in <code class="docutils literal notranslate"><span class="pre">app-portage/gpyutils/files/implementations.txt</span></code>.</p></li>
</ul>
</section>
<section id="porting-initial-packages">
<h3>Porting initial packages<a class="headerlink" href="#porting-initial-packages" title="Permalink to this heading">¶</a></h3>
<p>The initial porting is quite hard due to a number of circular
dependencies. To ease the process, it is recommended to temporarily
limit testing of the packages that feature many additional test
dependencies. The packages needing this have implementation conditions
in place already. An example follows:</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span> <span class="nv">PYTHON_TESTED</span><span class="o">=(</span> python3_<span class="o">{</span><span class="m">8</span>..10<span class="o">}</span> pypy3 <span class="o">)</span>
<span class="nv">PYTHON_COMPAT</span><span class="o">=(</span> <span class="s2">"</span><span class="si">${</span><span class="nv">PYTHON_TESTED</span><span class="p">[@]</span><span class="si">}</span><span class="s2">"</span> python3_11 <span class="o">)</span>
<span class="nv">BDEPEND</span><span class="o">=</span><span class="s2">"</span>
<span class="s2"> test? (</span>
<span class="hll"><span class="s2"> </span><span class="k">$(</span>python_gen_cond_dep <span class="s1">'</span>
</span><span class="s1"> dev-python/jaraco-envs[${PYTHON_USEDEP}]</span>
<span class="s1"> >=dev-python/jaraco-path-3.2.0[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/mock[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/pip[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/sphinx[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/pytest[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/pytest-fixture-config[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/pytest-virtualenv[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/pytest-xdist[${PYTHON_USEDEP}]</span>
<span class="s1"> >=dev-python/virtualenv-20[${PYTHON_USEDEP}]</span>
<span class="s1"> dev-python/wheel[${PYTHON_USEDEP}]</span>
<span class="hll"><span class="s1"> '</span> <span class="s2">"</span><span class="si">${</span><span class="nv">PYTHON_TESTED</span><span class="p">[@]</span><span class="si">}</span><span class="s2">"</span><span class="k">)</span><span class="s2"></span>
</span><span class="s2"> )</span>
<span class="s2"> "</span>
python_test<span class="o">()</span> <span class="o">{</span>
<span class="hll"> has <span class="s2">"</span><span class="si">${</span><span class="nv">EPYTHON</span><span class="si">}</span><span class="s2">"</span> <span class="s2">"</span><span class="si">${</span><span class="nv">PYTHON_TESTED</span><span class="p">[@]/_/.</span><span class="si">}</span><span class="s2">"</span> <span class="o">||</span> <span class="k">continue</span>
</span>
<span class="nv">HOME</span><span class="o">=</span><span class="s2">"</span><span class="si">${</span><span class="nv">PWD</span><span class="si">}</span><span class="s2">"</span> epytest setuptools
<span class="o">}</span>
</pre></div>
</div>
<p>It is important to remember to update the implementation range
and therefore enable testing once the test dependencies are ported.
Please do not remove the conditions entirely, as they will be useful
for the next porting round.</p>
<p>If only a non-significant subset of test dependencies is a problem,
it is better to make these dependencies conditional and run
the remainder of the test suite. If tests are not skipped automatically
due to missing dependencies, using <code class="docutils literal notranslate"><span class="pre">has_version</span></code> to skip them
conditionally is preferred over hardcoding version ranges, e.g.:</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span> <span class="nv">BDEPEND</span><span class="o">=</span><span class="s2">"</span>
<span class="s2"> test? (</span>
<span class="hll"><span class="s2"> </span><span class="k">$(</span>python_gen_cond_dep <span class="s1">'</span>
</span><span class="hll"><span class="s1"> dev-python/pydantic[${PYTHON_USEDEP}]</span>
</span><span class="hll"><span class="s1"> '</span> pypy3 python3_<span class="o">{</span><span class="m">8</span>..10<span class="o">}</span> <span class="c1"># TODO: python3_11</span>
</span><span class="hll"> <span class="k">)</span><span class="s2"></span>
</span><span class="s2"> )</span>
<span class="s2"> "</span>
python_test<span class="o">()</span> <span class="o">{</span>
<span class="nb">local</span> <span class="nv">EPYTEST_DESELECT</span><span class="o">=()</span>
<span class="hll"> <span class="k">if</span> ! has_version <span class="s2">"dev-python/pydantic[</span><span class="si">${</span><span class="nv">PYTHON_USEDEP</span><span class="si">}</span><span class="s2">]"</span><span class="p">;</span> <span class="k">then</span>
</span> <span class="nv">EPYTEST_DESELECT</span><span class="o">+=(</span>
tests/test_comparison.py::test_close_to_now_<span class="o">{</span>false,true<span class="o">}</span>
<span class="o">)</span>
<span class="k">fi</span>
epytest
<span class="o">}</span>
</pre></div>
</div>
<p>During the initial testing it is acceptable to be more lenient on test
failures, and deselect failing tests on the new implementation when
the package itself works correctly for its reverse dependencies.
For example, during Python 3.11 porting we have deselected a few failing
tests on <code class="docutils literal notranslate"><span class="pre">dev-python/attrs</span></code> to unblock porting <code class="docutils literal notranslate"><span class="pre">dev-python/pytest</span></code>.
Porting pytest in order to enable testing packages was far more
important than getting 100% passing tests on <code class="docutils literal notranslate"><span class="pre">dev-python/attrs</span></code>.</p>
<p>The modern recommendation for the porting process is to focus
on <code class="docutils literal notranslate"><span class="pre">dev-python/pytest</span></code> as the first goal. It is the most common test
dependency for Python packages, and porting it makes it possible to
start testing packages early. The initial ported package set should
include all dependencies of pytest, except for test dependencies
of the package with large test dependency graphs (<code class="docutils literal notranslate"><span class="pre">dev-python/pytest</span></code>
itself, <code class="docutils literal notranslate"><span class="pre">dev-python/setuptools</span></code>). This amounts to around 40 packages.</p>
<p>Note that emerging the initial set requires installing
<code class="docutils literal notranslate"><span class="pre">dev-python/pytest</span></code> with <code class="docutils literal notranslate"><span class="pre">USE=-test</span></code> first. Once it is installed,
the previously installed dependencies should be reinstalled with tests
enabled.</p>
<p>After pushing the initial batch, the next recommended goal
is <code class="docutils literal notranslate"><span class="pre">dev-python/urllib3</span></code>. It should be followed by focusing
on reenabling tests in the packages where they were skipped.</p>
</section>
</section>
<section id="python-build-system-bootstrap">
<h2>Python build system bootstrap<a class="headerlink" href="#python-build-system-bootstrap" title="Permalink to this heading">¶</a></h2>
<p>Python build systems are often facing the bootstrap problem — that is,
the build system itself has some dependencies, while these dependencies
require the same build system to build. The common upstream way
(actually recommended in <a class="reference external" href="https://www.python.org/dev/peps/pep-0517/#build-requirements">PEP 517 build requirements</a> section) is
to bundle the necessary dependencies as part of the build system.
However, this goes against best Gentoo practices.</p>
<p>The current Gentoo practice for bootstrap with dependency unbundling
is to:</p>
<ol class="arabic simple">
<li><p>Install the dependencies of flit_core and the eclass PEP 517 logic
(installer, tomli) manually using <code class="docutils literal notranslate"><span class="pre">python_domodule</span></code>.</p></li>
<li><p>Install flit_core using the standalone PEP 517 backend.</p></li>
<li><p>Install the dependencies of setuptools using flit (writing trivial
<code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> within the ebuild if necessary).</p></li>
<li><p>Install setuptools using the standalone PEP 517 backend.</p></li>
<li><p>The dependencies of other build systems can be installed using
flit, setuptools or other previously unbundled build systems.</p></li>
</ol>
<p>Note that for the purpose of bootstrap only obligatory baseline
dependencies are considered significant. Non-obligatory dependencies
(i.e. ones that can be missing during the bootstrap process) can be
placed in <code class="docutils literal notranslate"><span class="pre">PDEPEND</span></code>. Test suite dependencies can include cycles
with the package itself — running tests is not considered obligatory
during the bootstrap process.</p>
<p>flit_core has been chosen as the base build system for unbundling since
it has the fewest external dependencies (i.e. only depends on tomli).
Its author indicates in the <a class="reference external" href="https://github.com/pypa/flit/blob/main/flit_core/flit_core/vendor/README">flit_core vendoring README</a> that no other
dependencies will be added or vendored into flit_core.</p>
</section>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Gentoo Python Guide</a></h1>
<h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents:</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="preface.html">Preface</a></li>
<li class="toctree-l1"><a class="reference internal" href="interpreter.html">Python interpreters</a></li>
<li class="toctree-l1"><a class="reference internal" href="eclass.html">Choosing between Python eclasses</a></li>
<li class="toctree-l1"><a class="reference internal" href="basic.html">Common basics</a></li>
<li class="toctree-l1"><a class="reference internal" href="any.html">python-any-r1 — build-time dependency</a></li>
<li class="toctree-l1"><a class="reference internal" href="single.html">python-single-r1 — single-impl packages</a></li>
<li class="toctree-l1"><a class="reference internal" href="multi.html">python-r1 — multi-impl packages</a></li>
<li class="toctree-l1"><a class="reference internal" href="distutils.html">distutils-r1 — standard Python build systems</a></li>
<li class="toctree-l1"><a class="reference internal" href="distutils-legacy.html">distutils-r1 legacy concepts</a></li>
<li class="toctree-l1"><a class="reference internal" href="helper.html">Common helper functions</a></li>
<li class="toctree-l1"><a class="reference internal" href="depend.html">Advanced dependencies</a></li>
<li class="toctree-l1"><a class="reference internal" href="test.html">Resolving test suite problems</a></li>
<li class="toctree-l1"><a class="reference internal" href="pytest.html">pytest recipes</a></li>
<li class="toctree-l1"><a class="reference internal" href="concept.html">Advanced concepts</a></li>
<li class="toctree-l1"><a class="reference internal" href="expert-multi.html">Expert python-r1 usage</a></li>
<li class="toctree-l1"><a class="reference internal" href="buildsys.html">Integration with build systems written in Python</a></li>
<li class="toctree-l1"><a class="reference internal" href="porting.html">Porting tips</a></li>
<li class="toctree-l1"><a class="reference internal" href="migration.html">Migration guides</a></li>
<li class="toctree-l1"><a class="reference internal" href="qawarn.html">QA checks and warnings</a></li>
<li class="toctree-l1"><a class="reference internal" href="package-maintenance.html">Python package maintenance</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Maintenance of Python implementations</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#notes-specific-to-python-interpreters">Notes specific to Python interpreters</a></li>
<li class="toctree-l2"><a class="reference internal" href="#adding-a-new-python-implementation">Adding a new Python implementation</a></li>
<li class="toctree-l2"><a class="reference internal" href="#python-build-system-bootstrap">Python build system bootstrap</a></li>
</ul>
</li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="package-maintenance.html" title="previous chapter">Python package maintenance</a></li>
</ul></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©2020, Michał Górny, license: CC BY 4.0.
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 5.2.3</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
|
<a href="_sources/interpreter-maintenance.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>
|
GitWeb