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

[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@gentoo.org>
+# Python herd <python@gentoo.org>
+# @AUTHOR:
+# Author: Michał Górny <mgorny@gentoo.org>
+# Based on work of: Krzysztof Pawlik <nelchael@gentoo.org>
+# @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

[gentoo-dev] [python-single-r1 2/3] PYTHON_SINGLE_TARGET code for profiles.

[Michał Górny]

---
 gx86/profiles/base/make.defaults             |  3 ++-
 gx86/profiles/desc/python_single_target.desc | 15 +++++++++++++++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 gx86/profiles/desc/python_single_target.desc

diff --git a/gx86/profiles/base/make.defaults b/gx86/profiles/base/make.defaults
index ece143d..b3ae3bc 100644
--- a/gx86/profiles/base/make.defaults
+++ b/gx86/profiles/base/make.defaults
@@ -16,7 +16,7 @@ USE_EXPAND_VALUES_USERLAND="BSD GNU"
 
 # Env vars to expand into USE vars.  Modifying this requires prior
 # discussion on gentoo-dev@gentoo.org.
-USE_EXPAND="APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE"
+USE_EXPAND="APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE PYTHON_SINGLE_TARGET"
 
 # USE_EXPAND variables whose contents are not shown in package manager
 # output. Changes need discussion on gentoo-dev.
@@ -123,3 +123,4 @@ BOOTSTRAP_USE="cxx unicode"
 # Mike Gilbert <floppym@gentoo.org> (15 May 2012)
 # Default target(s) for python-r1.eclass
 PYTHON_TARGETS="python2_7 python3_2"
+PYTHON_SINGLE_TARGET="python2_7"
diff --git a/gx86/profiles/desc/python_single_target.desc b/gx86/profiles/desc/python_single_target.desc
new file mode 100644
index 0000000..dd70918
--- /dev/null
+++ b/gx86/profiles/desc/python_single_target.desc
@@ -0,0 +1,15 @@
+# Copyright 1999-2012 Gentoo Foundation.
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# This file contains descriptions of PYTHON_SINGLE_TARGET USE_EXPAND flags.
+
+python2_5 - Build for Python 2.5 only
+python2_6 - Build for Python 2.6 only
+python2_7 - Build for Python 2.7 only
+python3_1 - Build for Python 3.1 only
+python3_2 - Build for Python 3.2 only
+python3_3 - Build for Python 3.3 only
+jython2_5 - Build for Jython 2.5 only
+pypy1_8 - Build for PyPy 1.8 only
+pypy1_9 - Build for PyPy 1.9 only
-- 
1.8.0

[gentoo-dev] [python-single-r1 3/3] An example conversion of ebuild to python-single-r1.

[Michał Górny]

---
 gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild b/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
index 1ed3336..acaee2d 100644
--- a/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
+++ b/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
@@ -3,9 +3,12 @@
 # $Header: /var/cvsroot/gentoo-x86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild,v 1.9 2012/11/21 21:49:49 maekke Exp $
 
 EAPI=4
-PYTHON_DEPEND="python? 2:2.6"
+PYTHON_COMPAT=( python{2_6,2_7} )
 
-inherit cmake-utils eutils mono python
+# Note 1: this is actually a poor example. AFAICS libproxy should be
+# capable of being built for multiple implementations.
+
+inherit cmake-utils eutils mono python-single-r1
 
 DESCRIPTION="Library for automatic proxy configuration management"
 HOMEPAGE="http://code.google.com/p/libproxy/"
@@ -23,6 +26,7 @@ RDEPEND="gnome? ( >=dev-libs/glib-2.26:2 )
 	mono? ( dev-lang/mono )
 	networkmanager? ( net-misc/networkmanager )
 	perl? (	dev-lang/perl )
+	python? ( ${PYTHON_DEPS} )
 	spidermonkey? ( >=dev-lang/spidermonkey-1.8.5 )
 	webkit? ( >=net-libs/webkit-gtk-1.6:3 )"
 DEPEND="${RDEPEND}
@@ -33,8 +37,7 @@ pkg_setup() {
 	DOCS="AUTHORS ChangeLog NEWS README"
 
 	if use python; then
-		python_set_active_version 2
-		python_pkg_setup
+		python-single-r1_pkg_setup
 	fi
 }
 
@@ -69,10 +72,5 @@ src_configure() {
 	cmake-utils_src_configure
 }
 
-pkg_postinst() {
-	use python && python_mod_optimize ${PN}.py
-}
-
-pkg_postrm() {
-	use python && python_mod_cleanup ${PN}.py
-}
+# Note 2: build system doesn't compile Python files.
+# TODO: Introduce a public function to do that.
-- 
1.8.0

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

[Gilles Dartiguelongue]

Le mercredi 21 novembre 2012 à 23:19 +0100, Michał Górny a écrit :
> 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@gentoo.org>
> +# Python herd <python@gentoo.org>
> +# @AUTHOR:
> +# Author: Michał Górny <mgorny@gentoo.org>
> +# Based on work of: Krzysztof Pawlik <nelchael@gentoo.org>
> +# @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

you are missing the default EAPI value for EAPI=0 usually this is
written: case "${EAPI:-0}"

> +	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
> +

The rest looks fine.

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

[Thomas Sachau]

Michał Górny schrieb:
> 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.
> 

Maybe this is just a bit misleading, but let me ask to clarify this:

What exactly does "it finds the enabled implementation" mean? Is it
defined by the user (via a USE flag) or based on eselect-python target?

How does a dev define the implementation to be used and how does the
package manager output look like for sucht a package?


-- 

Thomas Sachau
Gentoo Linux Developer

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Fri, 23 Nov 2012 14:32:18 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> Michał Górny schrieb:
> > 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.
> > 
> 
> Maybe this is just a bit misleading, but let me ask to clarify this:
> 
> What exactly does "it finds the enabled implementation" mean? Is it
> defined by the user (via a USE flag) or based on eselect-python target?

Was in the last thread. Chosen through PYTHON_SINGLE_TARGET USE flag.

> How does a dev define the implementation to be used and how does the
> package manager output look like for sucht a package?

I don't understand the first question.

The output is, shortly saying, ugly:

[ebuild   R    ] net-libs/libproxy-0.4.10-r1::gentoo-cvs  USE="webkit* -gnome -kde -mono -networkmanager -perl -python* -spidermonkey {-test}" PYTHON_SINGLE_TARGET="python2_7* -python2_6*" PYTHON_TARGETS="python2_6 python2_7" 0 kB

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]