[gentoo-dev] [python-single-r1 1/3] A conceptual eclass for packages not supporting multiple Python impls.

[Michał Górny]

It's based on the PYTHON_SINGLE_TARGET variable concept. For that
reason, I used '-single' in the name. If someone could come up with
a better name, I'd be happy to use it.

It's used on top of python-r1. Similarly, you use ${PYTHON_DEPS} in your
RDEP/DEP; [${PYTHON_USEDEP}] can be used to depend on single- and multi-
implementation packages.

pkg_setup() is exported. It finds the enabled implementation, and
exports EPYTHON and PYTHON.

You aren't allowed to:

1) depend on python-single-r1 packages from python-r1 packages (why
would you?),

2) use python_foreach_impl() -- it will iterate over all implementations
in PYTHON_TARGETS, ignoring PYTHON_SINGLE_TARGET.
---
 gx86/eclass/python-single-r1.eclass | 93 +++++++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 gx86/eclass/python-single-r1.eclass

diff --git a/gx86/eclass/python-single-r1.eclass b/gx86/eclass/python-single-r1.eclass
new file mode 100644
index 0000000..3d21ea8
--- /dev/null
+++ b/gx86/eclass/python-single-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/eclass/python-r1.eclass,v 1.20 2012/11/21 09:04:14 mgorny Exp $
+
+# @ECLASS: python-single-r1
+# @MAINTAINER:
+# Michał Górny <mgorny@g.o>
+# Python herd <python@g.o>
+# @AUTHOR:
+# Author: Michał Górny <mgorny@g.o>
+# Based on work of: Krzysztof Pawlik <nelchael@g.o>
+# @BLURB: An eclass for Python packages not installed for multiple implementations.
+# @DESCRIPTION:
+# An extension of the python-r1 eclass suite for packages which
+# don't support being installed for multiple Python implementations.
+# This mostly includes tools embedding Python.
+#
+# This eclass extends the IUSE and REQUIRED_USE set by python-r1
+# to request correct PYTHON_SINGLE_TARGET. It also replaces
+# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
+#
+# Please note that packages support multiple Python implementations
+# (using python-r1 eclass) can not depend on packages not supporting
+# them (using this eclass).
+#
+# Also, please note that python-single-r1 will always inherit python-r1
+# as well. Thus, all the variables defined and documented there are
+# relevant to the packages using python-single-r1.
+
+case "${EAPI}" in
+	0|1|2|3)
+		die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+		;;
+	4|5)
+		# EAPI=4 needed by python-r1
+		;;
+	*)
+		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+		;;
+esac
+
+inherit python-r1
+
+EXPORT_FUNCTIONS pkg_setup
+
+_python_single_set_globals() {
+	local flags=( "${PYTHON_COMPAT[@]/#/python_single_target_}" )
+	local optflags=${flags[@]/%/(+)?}
+
+	IUSE=${flags[*]}
+	REQUIRED_USE="^^ ( ${flags[*]} )"
+	PYTHON_USEDEP+=,${optflags// /,}
+
+	local usestr
+	[[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
+
+	# 1) well, python-exec would suffice as an RDEP
+	# but no point in making this overcomplex, BDEP doesn't hurt anyone
+	# 2) python-exec should be built with all targets forced anyway
+	# but if new targets were added, we may need to force a rebuild
+	PYTHON_DEPS="dev-python/python-exec[${PYTHON_USEDEP}]"
+	local i
+	for i in "${PYTHON_COMPAT[@]}"; do
+		local d
+		case ${i} in
+			python*)
+				d='dev-lang/python';;
+			jython*)
+				d='dev-java/jython';;
+			pypy*)
+				d='dev-python/pypy';;
+			*)
+				die "Invalid implementation: ${i}"
+		esac
+
+		local v=${i##*[a-z]}
+		PYTHON_DEPS+=" python_single_target_${i}? ( ${d}:${v/_/.}${usestr} )"
+	done
+}
+_python_single_set_globals
+
+python-single-r1_pkg_setup() {
+	debug-print-function ${FUNCNAME} "${@}"
+
+	for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
+		if has "${impl}" "${PYTHON_COMPAT[@]}" \
+			&& use "python_single_target_${impl}"
+		then
+			python_export "${impl}" EPYTHON PYTHON
+			break
+		fi
+	done
+}
-- 
1.8.0