2. fedora-docs-l10n/packaging-guidelines
3. master/pages/Python_Appendix
4. English
5. Browse

1 / 6

/ 6

Read-only strings

• Untranslated strings • state:empty
• Unfinished strings • state:<translated
• Translated strings • state:>=translated
• Strings marked for edit • state:needs-editing
• Strings with suggestions • has:suggestion
• Strings with variants • has:variant
• Strings with screenshots • has:screenshot
• Strings with labels • has:label
• Strings with context • has:context
• Unfinished strings without suggestions • state:<translated AND NOT has:suggestion
• Strings with comments • has:comment
• Strings with any failing checks • has:check
• Approved strings • state:approved
• Strings waiting for review • state:translated

Position and priority

• Position and priority
• Position
• Priority
• Labels
• Source string
• Target string
• String age
• Number of words
• Number of comments
• Number of failing checks
• Key
• String location

	English
	Additional Python Guidelines
	Here are some additional Python-related guidelines, moved here in order to keep the main page manageable.
	Python 2 packages
	If your package needs to build for Python 2 only, follow the xref:Python_201x.adoc[201x-era Python guidelines], except substitute 3 for 2. For example instead of `+%{python3_sitearch}+`, use `+%{python2_sitearch}+`.
	Special emphasis on the rule that packages MUST NOT use `+/usr/bin/python+`.
	Naming
	The source package for a Python library MUST be named with the python- prefix except for a specific case bellow. A built package must include the Python major version in the name, using the python2- prefix. This is accomplished by adding a subpackage.
	If you need to package the python2 module as a separate source package (usually because upstream has dropped Python 2 support in newer versions but still supports the last version that works with Python 2), you MUST name the source package using the python2- prefix instead of creating a subpackage.
	Common spec files for python3 and python2
	It is possible to create both python3 and python2 subpackage from one common spec file. The following is a very simple spec file for a module building for both python2 and python3. It builds both versions in the same directory; this is possible because the build products for different versions of Python usually do not conflict.
	There are cases where it is not possible to build in a single directory. Most commonly this happens when the sources are modified during the build process to convert them from python2 to python3 using the the `+2to3+` tool (see bellow).
	As you can see in the `+%install+` section below, the order in which you do the python2 versus python3 install can sometimes matter. You need to be aware of when the install is writing to the same file in both packages (in this example, a script in `+%{_bindir}+`) and make sure that you're getting the version you expect.
	%global srcname example
	Name: python-%{srcname} Version: 1.2.3 Release: 1%{?dist} Summary: An example python module
	License: MIT URL: https://pypi.python.org/pypi/%{srcname} Source: %pypi_source
	BuildArch: noarch
	%global _description %{expand: A python module which provides a convenient example.}
	%description %_description
	%package -n python2-%{srcname} Summary: %{summary} BuildRequires: python2-devel
	%description -n python2-%{srcname} %_description