Project:Python

For users

 * implementations
 * PYTHON_TARGETS

For developers

 * conversion guide for python.eclass packages
 * Eclass API change history
 * eclasses
 * distutils-r1
 * python-r1
 * python-any-r1
 * python-single-r1
 * python-utils-r1
 * twisted-r1
 * Interoperability with other eclasses
 * waf-utils integration
 * Eclass design rationale
 * pypy-bin build instructions
 * python-exec script wrapper
 * test suites
 * virtual packages
 * USE flags on Python implementations

Adding packages
Anyone may add python packages to the tree. However, there are a couple of requirements if you want the python project team to maintain them.

The package must be a dependency of an existing package maintained by the python team in the tree.

OR

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 python to metadata.xml.

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.