Project:Python

From Gentoo Wiki
Jump to: navigation, search
Python
Description The Python project maintains dev-lang/python and most of dev-python/*.
Project email python@gentoo.org
IRC channel #gentoo-python
Lead(s)
Last elected: 2019/12/05
Member(s)
Subproject(s)
(and inherited member(s))
(none)
Parent Project Gentoo
Project listing

Python 2 end-of-life

By the end of 2019, Python 2.7 has reached end-of-life. Many projects have dropped Python 2 support already, and more are planning to do that. Gentoo is planning to continue providing its support where necessary for how long it's feasible to. However, this doesn't mean that we're going to go out of our way to provide support where upstream discontinued it.

More specifically:

  • Packages that support both Python 2 and Python 3 but have no remaining Python 2 reverse dependencies will eventually have Python 2 support removed and become Python 3 only.
  • Packages that support only Python 2 and have little chances of being ported to Python 3 will be removed eventually. The exact time of removal depends on usefulness and maintenance costs of individual packages.
  • Python 2.7 interpreter will be kept as long as necessary and/or feasible. We'll continue patching it if necessary. You can use it along with virtualenv/pip to support your py2 apps for the time being.
  • PyPy(2.7) support in packages has been removed already.
  • PyPy2.7 interpreter will be kept as it is necessary to build PyPy3.

Documentation

For users

For developers

Policy

Adding packages

Anyone may add Python packages to the repository, however there are a couple of requirements if you want the Python project team to maintain them:

  1. The package must be a dependency of an existing package maintained by the Python team in the tree.
  2. The package is a Python library with a significant level of demand from developers or users.

In either case, please ping a member of the Python team before adding the python project to the packages metadata.xml file.

For all added packages, the ebuild must define test phase if the upstream has some tests and they are not thoroughly broken by design.

Stabilizing packages

Stable request bugs may be created if the package already has stable keywords, or upon request.

Please do not stabilize packages with no stable keywords without some reason for doing so. Stabilizing packages increases the workload on both the Python team and arch teams, and this should be weighed against the value of having an ebuild with stable keywords.

ALLARCHES

Packages which are not platform-dependent may be stabilized according to the ALLARCHES policy, where a single arch tester may stabilize the package for all arches at once without testing on each individually.

Determining if the package is platform-dependent may be tricky, but here are some guidelines:

  • Most pure-Python packages may be considered platform-independent if they do not depend on architecture-specific values or functionality.
  • Packages which compile and install extension modules should be considered platform-dependent since they invoke the system toolchain.