Project:Python
| Python | |
|---|---|
| Description | The Python project maintains dev-lang/python and most of dev-python/*. |
| Project email | python@gentoo.org |
| Packages | p.g.o/python@gentoo.org
|
| IRC channel | #gentoo-python (webchat) |
| Bugs | Related bugs |
| Lead(s) |
Last elected: 2021-06-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 minimal support for packages that require Python 2 to build, and continue to ship the interpreters for as long as feasible.
The USE flags relevant to selecting Python 2.7 (and PyPy 2.7) have been removed. The few packages that require it at build time will pull the interpreter in automatically.
If you need to run your private projects via Python 2.7 (or PyPy 2.7), you can use dev-python/virtualenv to install the dependencies via pip. Note however that it's strongly discouraged.
While we do our best to backport security fixes from Python 3 to Python 2. At this point, Python 2.7 has unresolved vulnerabilities.
Documentation
For users
- Implementations
- python-exec script wrapper
- PYTHON_TARGETS variable
For developers
- OPML with dev-python/ version feeds (repo)
- generated via
user $gpy-release-feed-opml dev-python $(git grep -l python@ '*/*/metadata.xml' | cut -d/ -f1-2 | grep -v dev-python) > ~/git/python-site/release-feeds.opml- Gentoo Python Guide
- Conversion guide for python.eclass packages
- Eclass API change history
- Eclass design rationale
- Test suites
- Virtual packages
- USE flags on Python implementations
- Adding and Removing Python implementations to/from PYTHON_COMPAT
- Strict aliasing issues (-fno-strict-aliasing)
- Byte compiling Python modules
- Other issues
- Sphinx race conditions (e.g. FileExistsError: [Errno 17] File exists ...)
- gpyutils output
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:
- The package must be a dependency of an existing package maintained by the Python team in the tree.
- 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.
New Python versions
app-portage/gpyutils can be used to find packages that need to be tested with a new version of Python. Please do not file bug reports requesting that a new Python version be added to PYTHON_COMPAT.