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
|
==========================
Python package maintenance
==========================
Support for Python 2
====================
Since Python 2.7 reached EOL, Gentoo is currently phasing out support
for Python 2. Unless your package or its reverse dependencies really
need it, you should omit it from ``PYTHON_COMPAT``. If you're adding
a new package and it does not support Python 3, do not add it.
Many upstreams are removing Python 2 support from new releases of their
software. We remove it proactively whenever reverse dependencies permit
in order to anticipate this and avoid having to deal with lots
of reverse dependencies afterwards.
Packages that do not support Python 3 and are unlikely to start
supporting it soon are being slowly removed.
Which implementations to test new packages for?
===============================================
The absolute minimum set of targets are the current default targets
found in ``profiles/base/make.defaults``. However, developers
are strongly encouraged to test at least the next Python 3 version
in order to ease future transition, and preferably all future versions.
Marking for PyPy3 is optional. At this moment, we do not aim for wide
coverage of PyPy3 support.
Adding new Python implementations to existing packages
======================================================
New Python implementations can generally be added to existing packages
without a revision bump. This is because the new dependencies are added
conditionally to new USE flags. Since the existing users can not have
the new flags enabled, the dependencies do not need to be proactively
added to existing installations.
This usually applies to stable packages as well as new Python targets
are generally ``use.stable.mask``-ed. This means that stable users
will not be able to enable newly added flags and therefore the risk
of the change breaking stable systems is minimal.
Which packages can be (co-)maintained by the Python project?
============================================================
A large part of the Python ecosystem is fairly consistent, making it
feasible for (co-)maintenance by the Gentoo Python team.
As a rule of thumb, Python team is ready to maintain packages specific
to the Python ecosystem and useful for the general population of Python
programmers. This includes Python interpreters and tooling, packages
purely providing Python modules and extensions and utilities specific
to the Python language.
However, the Python team has limited manpower, therefore it may reject
packages that have high maintenance requirements. As a rule, Python
team does not accept packages without working tests.
If your package matches the above profile, feel free to ask a member
of the Python project whether they would like to (co-)maintain
the package. However, if you are not a member of the project, please
do not add us without asking first.
Porting packages to a new EAPI
==============================
When porting packages to a new EAPI, please take care not to port
the dependencies of Portage prematurely. This generally includes
``app-portage/gemato``, ``dev-python/setuptools`` and their recursive
dependencies.
Ideally, these ebuilds carry an appropriate note above their EAPI line,
e.g.::
# please keep this ebuild at EAPI 7 -- sys-apps/portage dep
EAPI=7
This does not apply to test dependencies — they are not strictly
necessary to install a new Portage version.
|
GitWeb